2

I want to provide a websocket based Service to my registered users. The Website Frontend is running on Server A, the WebSocket-Service is running on Server B.

I want to make sure that Server B won't grant acces to an user that is not authenticated by Server A. Also I want to avoid that a session can be hijacked.

I came up with this approach but I never implemented security for websockets. Might this be a good approach?:

  • When a client wants to connect with my WebSocket, Server A requests a token from Server B. The Server B will generate this Token and send it back to Server A.

  • Server B will store the token in a cache.

  • Now the client is allowed to connect to the WebSocket. The clients first Message contains the token.

  • Server B checks whether the token can be found in the cache and whether the token is already used by an active Session.

  • If everything is fine the client will be registered and is allowed use the service.

Is this a good approach? Is there a better solution I wont have to implement by myself?

I read this solution: Best way to create a TOKEN system to authenticate web service calls?

But since my users will send up to 500 messages per minute (thats the highest possible value..but still possuble) I think this could cause some trouble...

Community
  • 1
  • 1
Goot
  • 2,599
  • 5
  • 36
  • 56
  • Does this answer your question? [WebSockets authentication](https://stackoverflow.com/questions/2701373/websockets-authentication) – kag0 Aug 22 '20 at 00:09

1 Answers1

1

What is wrong with cookies?

If both servers are in the same 2nd level domain (web.example.com and websocket.example.com), they can share cookies.

The websocket connection will send the existing cookies for that 2nd level domain during the negotiation.

So you can perform authentication in the web server, return an authentication cookie, and then the websocket will send that cookie to the server again. The websocket server should be able of opening and reading the cookie.

"500 messages per minute" are 8 messages per second, it should not be a problem. Websocket connections are established once, there is not a new connection per each message. A websocket is different than a webservice.

Cheers.

vtortola
  • 32,045
  • 25
  • 144
  • 246
  • Thanks for your answer. How do you think could I avoid CORS attacks? Should I send the session cookie with the first message or is there a way to send that information while the connection is established? – Goot May 06 '14 at 19:21
  • The cookie is sent on connection, as part of the handshake. You should use a secure token as cookie value, then the security model is the same than in a normal web app. – vtortola May 06 '14 at 20:16
  • When my servers are on the same 2nd level domain, will the HttpSession ID be identical? In this case I wouldn't even need a cookie, right? – Goot May 06 '14 at 22:13
  • Probably the session id is already in a cookie. Check how your platform handles sessions, but probably there are already tools for session and authentication management. – vtortola May 07 '14 at 07:01
  • Hi, I just followed your answer but I'm facing a problem. How can I send the cookie to the websocket server? I'd like to do this during the handshake but I there is no httpsession to read. Can you take a look at http://stackoverflow.com/questions/23565223/websocket-handshake-has-no-httpsession-no-sharing-of-session-between-war-mod please? – Goot May 09 '14 at 13:18
  • I have no idea about Wildfly. If you are actually returning a cookie, the WebSocket connection should send that cookie, it is basic HTTP mechanics, so probably the problem is something related with Wildfly. – vtortola May 09 '14 at 13:43
  • maybe this happens because my cookie contains a path? Frontend: Domain: localhost, Path:Frontend; WS Path:Websocket – Goot May 09 '14 at 14:00
  • http://stackoverflow.com/questions/12755499/how-to-change-jsessionid-cookie-path-to-server-root-in-spring-app-on-jetty looks like I can't change the path to root – Goot May 09 '14 at 14:05
  • [Don't use cookies. Use tokens instead](https://auth0.com/blog/2014/01/15/auth-with-socket-io/) – Daniel says Reinstate Monica Jan 13 '15 at 22:13
  • Cookies are limiting when you want to build native apps or use CORS. See https://github.com/SocketCluster/socketcluster-client/issues/9 – Jon Feb 04 '16 at 03:48
  • There are additional CSRF issues with websockets since there is no SOP and you can't set headers. See here https://gist.github.com/kag0/f3c43b60b700af39563c050b29a3dfb2 for more on authenticating websockets with cookies. – kag0 Aug 22 '20 at 00:25