Need help on authentication architecture

Our team is building a small system in Node.js, and we're having a good time with Express and Sequelize so far. We're going to need an authentication solution in the next couple of months, though, and that's kind of worrying me right now. None of us have much experience with authentication in general. We've learned a couple of things about it in the Internet, but there are still important missing pieces in this puzzle.​Seeing as this new server (let's call it Server A) will share the same user database with another already established service running in the company (Server B), we thought they'd simply grant us access to this database in order to authenticate the users through Passport.js. They suggested doing something else entirely, to our surprise.​The suggestion goes as follows: the users will log in through Server B and be redirected to our new server by clicking a specific link in their user page. Server A would then receive a request from Server B with a special token containing some data about the authenticated user (email, resources he is authorized to read and edit, and so on), and take it from there. This way, Server A wouldn't need to query the user database in production and all authentication would remain entirely in Server B. We wouldn't even need to worry about HTTPS in Server A: once the user authenticates in Server B via HTTPS and their useful data are transferred to Server A, they wouldn't need to maintain a secure channel with Server A after that.​The main questions here are:​1- Is this architecture really feasible? Would we really be able to avoid using HTTPS in Server A if the authentication part is only used in Server B?​2- How would Express support this? In theory, they think we could achieve this by only treating the requests to the Server A home page, by checking if they come from Server B, and then proceeding to store the data received in a session or JWT token. Is it really that simple? How would Server A understand that the request from Server B is just an information to be used in a connection with another client? Would Passport.js be able to handle this situation somehow?​3- Would you use sessions or JWTs for this job?​4- Would we run into immediate CSRF problems or at the very least risk both servers this way?​5- Should I insist on the shared database solution, considering we just need a read-only access on it and it'll probably make things easier? I mean, we would only need to construct get/post routes for login and implement their logic, basically. The only extra challenge I can see with this approach is incorporating SSL/TLS in our service, something that's not part of the initial scope, but I feel it might probably be both more critical and easier to implement than I thought.​​Any help is appreciated. Thank you all in advance!

Submitted November 30, 2019 at 07:52PM by geoplasma