Runtime Authorization/Security reload

[Biacode]

Feature Request

The NATS server/client could support runtime auth/security context reload.

Use Case:

If I am connected to the NATS server with a JWT token for the X.Y.Z topic, I should be able to change my JWT without re-connecting to the server.
This could be a chat application. So you have access to the a.b.c session, then requesting for access to the x.y.z session and change your JWT without the required re-connect.

Proposed Change:

The changes should be made for both - the server and the client

Who Benefits From The Change(s)?

I think any client application that requires some User JWT will benefit from this feature.

Alternative Approaches

The main goal is to do this without re-connect. I don't see that many options here.

[derekcollison]

100% agree and this has been in discussions for awhile. We will be turning our attention more towards the clients soon (we have alot!) and this as well as general simplifications, smart reconnect etc. are all on the table.

[Biacode]

Thanks, @derekcollison, any idea where I can track this table? Surely many clients will benefit from this feature.

[derekcollison]

Might make sense to create a discussion from this.

[Biacode]

Any info on this? Where would you like to create a discussion?
The feature is convenient.

[windmeup]

It's very useful for me

[derekcollison]

In your scenario, how would the new JWT be delivered to the client in order for the client to resend to the server?

[Biacode]

Hi @derekcollison. I plan to sign valid user JWT using the Java back-end and NATS Account in my scenario.

[derekcollison]

But you would need to get that to the end clients so they can resend to the server to change the JWT "on file" for the connection.

[Biacode]

Hi @derekcollison, you didn't need any JWT file when you signed ephemeral User's JWT. I use Java SDK JwtUtils to generate a JWT token and authorize the connection. So no file is needed. You can create the token using the NATS account signing key (decentralized security).
The flow is the following:

• Given we have a user
• When the user authenticates in internal back-end
• Then, the user can request a NATS JWT token (authorized)
• Then, the user can connect to the NATS server using the JWT token
• Then, the user can request a new NATS JWT token without closing the existing connection (to subscribe or publish on different NATS topics).

I hope this helps

[derekcollison]

Yes that helps, what I was asking you solved for but the app/client requesting new tokens. That is what I meant by the JWT needs to make it way to the app somehow.

[Biacode]

Hey folks. Any forecast on when this could be included in the NATS server? I can contribute to the Java and JS client-side implementation. Or even Go-Lang if you give me some hints on where to take a look.

[derekcollison]

We are doing some client planning now (this is more client then server), will keep you posted.

[Biacode]

As a suggestion, I think it would be reasonable to unsubscribe from all the previous subscriptions that the client has (after changing the JWT key).
This could also be delegated to the client and make it responsible for tracking the subscriptions and unsubscribing when needed. But perhaps some simple flag/parameter could do the job (e.g., pass argument like unsubscribe all, etc.).

[Biacode]

Hello.
I wonder if there is any progress on this. Also, bumping the issue.
@derekcollison

[derekcollison]

Yes we are progressing, lots of different requirements from different users/customers but you should see something hopefully before end of year.

[szdanowski]

@derekcollison Are there any updates around this issue? Is it still looking as something that can be available by the end of the year?

[derekcollison]

This is planned for the 2.10 release, that and auth (and generic) callouts. The clients will need to be updated after server properly supports this but it will happen as part of the auth callout work with is the top priority after any bug fixes etc.

[derekcollison]

I will code this out next week.

[windmeup]

I will code this out next week.

Is there any progress?

[derekcollison]

Yes its completed and in the dev branch and part of the dev nightly builds which will become 2.10 probably sometime in May.

The auth callout also has its own ADR which has been kept up to date. So all there already and ready for the 2.10 release.

[brettinternet]

Can this be accomplished now by updating the UserJWT on Opts?

nc, err := nats.Connect(...)

nc.Opts.UserJWT = nats.UserJWT(userCB, sigCB)

[Jarema]

@brettinternet unfortunately, no.
The Auth Callout is released, but that is a more complex solution.
We are planning simple auth-refresh to be worked on soon.