I post here to know if my authentication mechanism over websocket is sound.

My app API works over websocket instead of the standard HTTP rest. Each time a path that is secured is accessed over websocket, the JWT is sent with the websocket message on the client to the server. On the server, if the resource accessed needs authentication the JWT is verified.

I'm using sockJS and on their github they state:.

An iframe is hosted from target SockJS domain. That means the server will receive requests from the iframe, and not from the real domain. The domain of an iframe is the same as the SockJS domain. The problem is that any website can embed the iframe and communicate with it - and request establishing SockJS connection. Using cookies for authorisation in this scenario will result in granting full access to SockJS communication with your website from any website. This is a classic CSRF attack.

But this doesn't seem to apply to JWT over websocket instead of cookies in HTTP, or does it?

I'm also left wondering if I could authenticate only once and keep a flag authenticated: true on the server side of the websocket connection. It makes sense to not have to authenticate the user upon each request.

As I understand JWT, they are time limited with expire, so that wouldn't work, right?

So to summarize:

  • Can I authenticate only once?
  • Is there any obvious flaw here, like CSRF?
  • What did you end up doing here? I am basically trying to track down the answer to this myself. Once the initial handshake is authenticated, is there any reason to continue authenticating subsequent messages? Oct 23, 2017 at 13:49
  • @TheBrewmaster I ended up setting an authenticated flag and the token on my connection. If the user does smtg over websocket that requires authentification then I check the flag, and I check if the token is still valid. No need to resend the token on every message sent :)
    – Ced
    Oct 23, 2017 at 13:52


You must log in to answer this question.

Browse other questions tagged .