Securing websockets

[gilded wing]

I am trying to figure out how best to secure some websocket gateways that sit beside my 'normal' http things.

My authentication system currently works like so:

1. user signs in with username / password

2. I issue a short lived access token directly to them in response body and send a refresh token as a signed http-only cookie

3. when a user attempts to access some part of the api, the client's process is generally to grab an access token from the refresh endpoint (relying on its cookies) and then do the operation, after which it throws away the access token (it expires very quickly)

So, now, knowing this...I am trying to figure out how to get my websocket secured, as I'll probably need a longer lived token to continue authorizing stuff while the user is connected to the websocket.

I guess, before they connect, the client can grab an access token, send that along with the websocket connection, and I can set up a lifecycle listener to quickly grab the access token, validate it, and then issue a third type of token that is longer lived that they can hold onto while they're active on the websocket...

I mean, I think it will work? But I'll need a new guard, I think. Has anyone done something similar? I'd appreciate other ideas or if my idea is good, just some validation. Thanks

[molten sigil]

@gilded wing - Sort of on a side note. I think your understanding of refresh and access tokens is a bit off. The client should be sending an access token for any request. Your authz system takes it and determines if the access token is valid and if the authz it holds is valid for the requested resource/ endpoint. Considering only the validity of the access token, if it is invalid, the client should get a "not authorized" response from the server. The client should then (automatically) hit the refresh end point with the refresh token to "ask" for a new access token. If the refresh token is valid, the client gets a new access token and refresh token (best practice). Now the client can rerequest the initial resource/ endpoint with the newly refreshed access token. This whole process should be completely automatic.

As for websocket connections, the access token check can be made when the inital request for the web socket upgrade is made. Access token is valid? Upgrade to the socket. 🙂

[gilded wing]

Yeah it is automatic, it's just not working in the way you just described, though I can edit it to work that way if that's the best practice. The way I made it is that the access tokens are extremely short lived. Client gets the refresh token, uses it to grab an access token, does whatever it needs, and by then the access token is already expired. I guess that's a bit too much, though. Anyway, I can change that, it's not a big deal.

For the websockets, what you said is what I was thinking. However, due to my extremely short lived access tokens, I'm trying to figure out how to continue to guard stuff inside the socket. Client connects with the access token, server validates the access token and lets them in, but now the client wants to send a specific message. In nest, that's going to hit a handler (with the @subscribemessage decorator) that has a guard on it. My current guard that I use for http handlers is not going to work, since it's checking the access token in the header, which is going to be expired.

Hope I'm making sense.

Maybe I need to change how my tokens work like you're mentioning

Ah, actually...I guess once they're on the socket, and the access token is validated, I have their user object and their associated authorization claims...so no further tokens needed.

🤡 silly me...(I hope)

[molten sigil]

Yes, once a web socket connection is made, it doesn't need the access process anymore or rather the access token methodology to protect the web socket endpoint is no longer applicable. The client is "connected" to the server, unless either the client or server break the connection. You can still, however, pole the server for a new access token, before the refresh period is expired. If that process fails, the server would kill the web socket session.