Identifing websocket client session when using httpOnly cookie and auth callout

[jonaskello]

Now that we have the possibility to use httpOnly cookies to pass a value to auth callout it is almost possible to only use httpOnly cookie when doing NATS rpc call from the browser to replace regular HTTP request/response. The final hurdle I have is to be able to identity the calling client's session without leaking that information to the javascript in the browser (for regular HTTP request this is fully solved using httpOnly cookie).

What we are doing is setting a httpOnly cookie with a sessionId in a traditional way from a regular HTTP backend. This sessionId is stored in a backend memory database (redis) together with other information such as tokens needed to make other backend calls etc. Then we connect with nats.ws from the browser to NATS server and since we have token_cookie configured this sessionId is forwarded to the auth callout service. The auth callout service validates the session on the backend and issues a JWT. All this can be done without leaking the sessionId to the browser code since we can use httpOnly cookie for this whole flow.

However we also need to be able to know which sessionId is making RPC calls into NATS. For example a service running in NATS may have to make calls using one of the tokens associated with the session, so it needs to get session info from redis. This is possible in several ways already for example we are currently putting the sessionId in the subject. However this is no longer possible with httpOnly cookie since we cannot read the cookie in the browser code. So we need some other way to do this part if we want to use httpOnly cookie (which we want because it is more secure). I have considered the following solutions:

1. Putting the sessionId in the subject and limit the issued JWT to something like {sessionId}.foo.getBar. This works and allows the service receiving the call to have the sessionId similar to how it gets it in a cookie header for a regular HTTP request. However as I mentioned above it requires the browser javascript to have the sessionId available in order to contruct the subject. This means we cannot have it only as httpOnly cookie and thus it is leaked into the client code.

2. Getting hold of the NATS client_id field in the auth callout and restrict the subject to {client_id}.foo.getBar. Then somehow get hold of the client_id in the browser (I don't think nats.ws currently exposes this but from what I understand it is returned from INFO call in the NATS protocol). On the backend in the auth callout server associate the client_id with the sessionId. This avoids exposing the sessionId in the client code but in RPC calls we can extract the client_id from the subject and then use it to lookup the sessionId. As an alternative we could generate some unique ID in the auth callout servcie and use that instead of client_id. But I don't think there is a way to communicate something like this back to the connecting client from the auth callout service?

3. In the JWT that the auth callout issues put subject mapping rules so that foo.getBar is mapped to the_session_id.foo.getBar. This way we do not need to expose the sessionId to the browser and NATS will automatically add it to the subjects by mapping. However from what I understand the JWT that is issued by auth callout cannot have subject mappings, only account tokens can have this.

Guidance and more ideas are very welcome!

[aricart]

This has nothing to do with the connection or the session per se. NATS interactions are anonymous. If you have permission, you can, but who is making the request or responding is only known if you include additional information. Now, with that said, the correct pattern for this is to encode the id/session information as part of the subjects. The client would only be able to publish messages including this ID (the server that set the auth cookies could reveal this to the web application so that the client can setup itself with an inbox that looks like _INBOX.aid.someid.> as a prefix, and then for the request subjects publish to q.someservice.aid.someid, the callout should ensure that the client only has permissions to subscribe to things that include such pattern correctly, ensuring that no other client can publish or subscribe to messages intended for the particular client. Your application then, knowing this session can figure out who the client is and behave accordingly. There's a possibly outdated example that you can look at for some insight that used this strategy (https://github.com/aricart/authdemo).

[aricart]

Also, remember that you can always make your HTTP server proxy the interactions with NATS; in that case, you can simplify a lot of the interactions and handle all the security within your app rather than have the browser reach in.

[jonaskello]

the permissions that you are minting will not allow any other client to publish on this

Yes this is 100% true and we are already doing it this way. By doing this it is 100% certain that the client is the only one being able to publish because the connection with the corresponding token is the only one that has rights to publish on the subject. We are fully aware of this part :-). Looking only on this part in isolation it is secure. This is not the problem.

so it is inconsequential if the id is seen

It is inconsequential in the way that it just has to match the one in the token to make sure that the client is the only one that can publish on it. But it is not inconsequential in the way that the id itself must be OK to may be stolen by an XSS attack without causing harm. You may think that even if someone stole the id then it is still no big deal since they can not publish on the corresponding subject since they do not have the connection with the corresponding token that allows publishing with that id. In theory this is correct if you just look at this particular part of the flow. However if you consider the full flow trying to make this secure inside the browser is in practice not really possible.

The problem is that in order for the id to be useful it must be meaningful to the server. So if the client just invents some id that it sends along when connecting that would not be meaningful to the server. So the server must be the one to create the id and it must associate it with something on the server-side like a user session. So the problem lies with the server having to create the id and associate it with something and that XSS attacks are possible. Maybe it is easier to explain with one of the full flows that does not work as an example:

1. The HTTP server logs the user in and sets a httpOnly cookie with the sessionid.
2. The browser websocket nats client connects sending along the sessionid from the cookie.
3. The auth callout service is called and receives the sessionid.
4. The auth callout service creates a new unique id to be used in the subject (rather than using the sessionid becuase that should not be exposed to the browser). It adds this id to the minted JWT subjects so only this client can send on subjects that have this unique id. It also associates this new unique id with the sessionid so when services later gets the id on the subject they can lookup the session id.
5. Here it breaks down because there is no way (that I know of) for the auth callout service to communicate the generated unique id back to the browser client that is connecting. So it will have no way of knowing that it should use this id in the subjects it publishes on. Even though it would be OK to have that id exposed in the browser and stolen by XSS attack as it is not the session id and it will always be re-generated so it cannot be used for new connections. If there was some mechanism to communicate the id back to the client then this flow could work.

Also, remember that you can always make your HTTP server proxy the interactions with NATS; in that case, you can simplify a lot of the interactions and handle all the security within your app rather than have the browser reach in.

The subject is the only way to identify the client. There is no server proxy I know of that can alter NATS subjects because that would mean it has to be able to decode the NATS protocol? So there is no proxy that can help with this AFAIK.

[aricart]

What I mean is your application (on the HTTP server) can make the NATS requests for you. Currently you are putting the logic on the browser, but the same could be an URL that you hit that will get all your auth information with each request and you can validate and then do what is needy.

[jonaskello]

You mean like writing a custom HTTP gateway and hiding NATS behind it rather than exposing NATS via websockets to the browser? Yes we've considered this as it might be the only way to make things secure.

However using nats.ws from the browser has been working very well for us during development and beta. Now that we are moving towards production we need to be more security aware. NATS is also very performant and easy to use for streaming. Introducing a HTTP proxy will introduce extra latency and on top of that streaming does not work well with HTTP so even if we could proxy the RPC calls easily, streams will be more difficult. Simply calling into NATS from the browser is much simpler and more efficient. Only thing is that we cannot find a fully secure flow for it but it is very close. I think #5147 could solve the final piece. Do you have any thoughts about that proposal?

[aricart]

The main issue here is that you are asking for the NATS server to do message source attribution, which I am certain breaks an important tenant for NATS.

[derekcollison]

If a message is received via a service import information about the client is provided. Minimal unless the import specified share as true and then full fidelity of all information about the client is provided in a header.

…

On Thu, Feb 29, 2024 at 4:15 PM Alberto Ricart ***@***.***> wrote: The main issue here is that you are asking for the NATS server to do message source attribution, which I am certain breaksvided in an important tenant for NATS. — Reply to this email directly, view it on GitHub <#5143 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAV74LN6QR7TM42MP6HCCTYV6T7DAVCNFSM6AAAAABD6T4VECVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DMMZWGI3TO> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[jonaskello]

Yes I read about this in #4920 that NATS add the "Nats-Request-Info" header in this case. We are currently not using imports but perhaps we can re-arrange things to use imports in order to trigger this. I'll try some experiment and see if we can use this.

Btw #4920 and the "Nats-Request-Info" header was also what inspired the proposal in #5147 which I think is similar but instead of triggering headers being added by import, they are triggered by the content of the JWT issued for the client.

[jonaskello]

After some more experimentation I think I may have a full flow that is secure. It uses the client_id that is generated by NATS for each new connection as this value is available both to the auth callout service and the client (I found that it is actually a property of the connection which I did not know before). I think there is guarantee that client_id is always unique for each connection and cannot be re-used for new connections. If this is true, then it does not matter if client_id is stolen in a XSS attack as the attacker cannot use it for a new connection (which he could with a generic session_id).

So the full flow would be:

1. The HTTP server logs the user in and sets a httpOnly cookie with the session_id which is stored in the backend database together with other items, such as access tokens needed for making further backend calls. Making the cookie httpOnly means the session_id cannot be stolen with XSS.
2. The browser websocket nats client connects sending along the session_id from the cookie (using the token_cookie websocket config).
3. The auth callout service is called and receives the session_id which it validates with the backend database.
4. The auth callout service finds the server_id:client_id that the NATS server generated for the connection in the auth request. It puts a mapping between the server_id:client_id and the session_id in the backend database.
5. The auth callout service issues a token that allows the client to only publish on subject {server_id:client_id}.>. This way we can be sure that any messages published on this subject originated from this client.
6. The websocket nats client finds the server_id:client_id from the connection properties and prefixes the subject for rpc calls with this, for example {server_id:client_id}.myService.getFoo
7. The service that responds to *.myService.getFoo extracts the first part of the subject to get the server_id:client_id and then looks up the corresponding session_id in the backend database. It can then look up any other information associacted with the session_id such as an access token it needs to make a http call to some other service.

It is also possible to use export/import and the "Nats-Request-Info" header to replace the need for subject prefixing. This header also contains the server_id:client_id IMO this is a nicer solution as it does not pollute the subjects and also simplifies the auth callout service as it des not need to put the prefixed restriction on the subject in the issued token.

[derekcollison]

Generating the info per message can be penal when you have some message rates that are in the millions. So we limited it to service export/import, but please note that you can do this seamlessly inside the same account, with no impact to the end user applications code. Just export and import to the same account.

[jhalag]

That makes a lot of sense. I can see why one would not want those headers appended to high volume, low size messages.

I was not aware that an import/export within the scope of a single account would be valid. In the back of my mind I thought I had read that such would be ignored. That's actually not too heavy for configuration overhead - I could set up wildcard topic(s) for the API entries I need tracking on - and leave the others lean.

Thank you for the clarification @derekcollison !

[derekcollison]

No problem. Let us know if you have any issues.

[jhalag]

Ah, I found the reference that had me thinking an account could not import from itself: https://docs.nats.io/running-a-nats-service/configuration/securing_nats/accounts#import-configuration-map

There it states "Accounts cannot do self-imports."

[derekcollison]

Yes that used to be the case, we will update the docs. Thanks for the reminder. /cc @bruth

[derekcollison]

They are used only once per server, so it has to be serverid:CID

[jonaskello]

Aha, thanks, I did not know that. You're correct that if the name field containing the session_id gets exposed to the client then it will be comprimised becuase is not a nonce like the server_id:client_id field.

The reason for using name was that it simplifies the implementation of the auth callout service since in that case it does not need to have access to the session database, and also the services do not need to do double lookup in the session database.

It would be nice if there was a field that auth callout could set in the issued jwt that was guaranteed to not get leaked back to the client, and also was included in "Nats-Request-Info".

[aricart]

But name is intended as a way of identifying a client on monitoring...

[jonaskello]

Yes, as I said above it would be nice if there was another field we could use besides name that would be more dedicated to the application's needs. To clarify, the needs of the field are:

1. Possible to set from auth callout.
2. Guaranteed to not get leaked back to the client.
3. Included in "Nats-Request-Info".

I don't think there is such a field already (name was the only candidate I found). Just suggesting it would be nice if id could be added.

[aricart]

I think that since we only expose fields that are part of the auth, adding additional things without some sort of design contract is not really feasible. Given that you should just use the info there and then retrieve from your back end, it is best for your application to determine what those requirements are rather than try to build something based on some place holders that we provide which won't meet other applications needs.

[jonaskello]

From my perspective as an application developer using NATS I think the auth callout feature and the "Nats-Request-Info" feature are two huge steps forward to enabling more flexible auth scenarios for applications using NATS. An extra field in the jwt for application specific use would enable any application to add any application specific value and then get it back on each call. I still think that would be yet another good step towards a more flexible auth story. I'm not sure what "design contract" refers to here but IMO the 3 requirements I stated above would be a design contract for this field.