To do that, the easiest way is to keep your current login forms but instead of POSTing them to your local apps, we’ll POST them to a centralized authentication API.(SSL is strongly recommended) As shown above, the login form now submits to an endpoint in the authentication application.We have three web applications running on different subdomains and sharing account data via a centralized authentication service. That said, if you migrate an existing app to an architecture like that, you will spend 80% of your time decoupling your legacy code from authentication and wondering what data should be centralized and what should be distributed.Unfortunately, I can’t tell you what to do there since this is very domain specific.Internally, the Authentication app will validate the identifier (email or login) using a hashed version of the clear password against the matching record in the account data.If the verification is successful, a token will be generated containing some user data (for instance: id, first name, last name, email, created date, authentication timestamp).
For security reasons, you might want to white list the domains you allow your authentication app to redirect to.
I wish these two words didn’t share the same root because it surely confuses a lot of people. Every time I start talking about implementing a centralized/unified authentication system, someone jumps in and suggests that we use OAuth.
The challenge is that OAuth is an authorization system, not an authentication system.
If the verification failed, the token isn’t generated.
Finally the user’s browser is redirected to the callback/redirect URL provided in the request with the token being passed.