Working on an application using Node.js/Socket.IO that requires wide browser compatibility, so its expected that clients may not have WebSocket support in their browsers. I wanted to know whats the most robust way to authenticate users no matter the underlying transport.
There are a number of examples which send a cookie with the sessionID on the connect/handshake which is ideal but I’m concerned that this wont work with Flash Sockets as the cookies sent are different.
The other approach is to get the client to store the SessionID when the user authenticates and then when the user requires Socket connection you send the session ID though as the first message. The issue with this approach is you incur overhead of establishing a full connection which is not ideal from a load or security perspective.
What is the best authentication pattern using Socket.IO during the connection/handshake phase (i.e. not sending a token through the connected socket), not matter what underlying transport mechanism is used between the client & server?
My thought is that you can’t avoid sending authentication on an open socket. You’re going to need to link that socket to something you have internally, even if you restrict the use of sockets to the real-time aspects of your application, unless you are providing read-only public streaming.
You can reduce connection overhead by authenticating via another mechanism, say Express/Redis and only instruct the client to open a socket connection (sending the session ID as first communication over the socket) if authorization is valid. You have to do this manually in your client code; you’re right that cookies won’t be sent automatically over a Socket.IO connection. You can immediately disconnect sockets that pass an invalid session ID or send a request with no session ID, and have a much more strict timeout for those connections if DoS attacks are your concern. See Socket.IO Authentication for some example code on how to implement this.