Identifing websocket client session when using httpOnly cookie and auth callout #5143
Replies: 4 comments 28 replies
-
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 |
Beta Was this translation helpful? Give feedback.
-
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>
|
Beta Was this translation helpful? Give feedback.
-
After some more experimentation I think I may have a full flow that is secure. It uses the So the full flow would be:
It is also possible to use export/import and the |
Beta Was this translation helpful? Give feedback.
-
They are used only once per server, so it has to be serverid:CID |
Beta Was this translation helpful? Give feedback.
-
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. ThissessionId
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 withnats.ws
from the browser to NATS server and since we havetoken_cookie
configured thissessionId
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:
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 thesessionId
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.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 theclient_id
in the browser (I don't thinknats.ws
currently exposes this but from what I understand it is returned fromINFO
call in the NATS protocol). On the backend in the auth callout server associate theclient_id
with thesessionId
. This avoids exposing thesessionId
in the client code but in RPC calls we can extract theclient_id
from the subject and then use it to lookup thesessionId
. As an alternative we could generate some unique ID in the auth callout servcie and use that instead ofclient_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?In the JWT that the auth callout issues put subject mapping rules so that
foo.getBar
is mapped tothe_session_id.foo.getBar
. This way we do not need to expose thesessionId
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!
Beta Was this translation helpful? Give feedback.
All reactions