I am creating angular2-login-seed that uses Passport.js with OAuth authentication strategies. Obviously, the default authentication method with these tools is to use an HTTP cookie signed by express. The passport, from what I can say, controls the actual Set Cookie header so that express can authenticate each subsequent request through request.isAuthenticated() and access the data set by the passport through req.session.passport.dataHere .
I want to include real-time data in an application through websockets. This, of course, means a socket stream coming from the server to the client. This message is completely different from a normal HTTP server request, meaning:
It does not contain an HTTP cookie that contains all HTTP requests.
Express does not interact with sockets, it is controlled by any implementation used in the backend (sock.js, socket.io)
This makes it difficult to optimize authentication between HTTP requests to express and websocket data on the backend, as they are separate communication methods.
From my research, this leaves me with two options. One of them is to use the library to provide my socket implementation (preferably sock.js via socket.io, but I need to do more research) for an express session. Then I could authenticate the socket connection, but I want to. The problem is that I have no idea how to get the express cookie in the stream from the front, since javascript cannot access it (HTTP cookie).
Another common solution I've seen people with is to use JWT (JSON Web Tokens). The implementations revolving around this store are JWT's front-end localstorage. This means that the SPA (in my case Angular2) can send it with every request for server authentication without taking into account the state, and we could send it via websocket to authenticate the connection with websocket (the JS interface has access to localstorage obviously). A couple of things that come to mind when you think about this implementation:
Is it possible for Passport OAuth strategies to use JWT instead of regular session information? What modification does this entail? From what I can tell, Passport strategies use some form of parent OAuth1 or OAuth2 authentication strategies, which uses cookies by default.
By storing this important information in localstorage, open the application before security breaches (XSS, CSRF, etc.)
If so, the most common workaround I have seen is to save the JWT in a cookie, so it cannot be easily obtained, tampered with, or tampered with. However, this brings me back to the position I was in before using the JWT, so maybe that doesn't bother.
Does this mean that I will need to use some kind of backend state management repository (like Redis) to control the authentication and decryption of the JWT body? (I don't know anything about Redis, etc.).
The idea of connecting authentication between server HTTP requests and socket data is odd, but seems to be vital for proper socket connection authentication. I am a little surprised that a simpler method does not exist. I did some research and saw things like socketio-jwt , express-jwt , etc. However, I do not know if it was a controlled transition with my passport strategies, or if it was easier to open the express session data in the socket implementation, or if I was going to get it all wrong!
Any help or guidance would be greatly appreciated.