
Here is an example of how login could work, as well as the interaction between the Auth Server and Application Server: It is filled with all the information related to the application (except for authentication information). The only way to access it is by going through the Auth Server. It is not accessible from the outside world.It performs no authentication, relying entirely on the X-UserId header from the Auth Server.This is a normal web application server.The Application Server will not even be aware of these requests. It will handle these requests completely on it's own. It will have specific routes for logging-in, logging-out, and registration (for example, /login, /logout, and /register).If there is no cookie with authentication information, or if the session information is incorrect, then it forwards the request to the application server without the X-UserId header.

If the session information is correct, it adds an X-UserId header to the request and forwards it to the Application Server.

This session information would be proof that the user has logged in correctly at some point in the past.

In a lot of our web apps we would like to support OAuth login from the various providers as well as email-based registration.

One part of the web app that is often repetitive to write is the authentication system. I work at a small consultancy and we often make web apps for our clients.
