I have an ASP.NET MVC site that runs on www.company.com and has all the user registration and login pages etc.
I would like to start migrating the site to an angular application with asp.net web API on app.company.com
The user would login to www.company.com, and parts of the site will (seamlessly to the user, aside from the URL change) go to app.company.com
If I set up auth0 to be the user management service for www.company.com, then how can I have a seamless sign on experience with app.company.com? app.company.com would need to know who the authenticated user is, even though that user authenticated against www.company.com
Your main goal is for the user to authenticate only once so if you remove the details about this being part of a migration process from one tech stack to another you could easily describe this generically as implementing SSO between two applications and doing so through Auth0.
The above SSO scenario is supported, the important part is that when the end-user authenticates it does so in a way that creates an authenticated session at your Auth0 account and then that session can be reused by any other apps as a way to not force the end-user to actively authenticate again.
For two generic client applications A and B associated with an Auth0 account named idp the flow could be something like this:
- The end-user accesses application
A which has no idea who the user is so it makes a non-interactive request to idp as a way to verify if the current end-user has already authenticated.
- If the end-user never authenticated before application
A is notified of that and redirects the end-user to the idp authorization endpoint where the end-user will authenticate through the hosted login page.
- If the end-user already authenticated before application
A will receive the user identity and any applicable tokens and proceed to treat the end-user as authenticated.
- The end-user accesses application
B which has no idea who the user is and a similar dance as above is done, however, now the user is already authenticated so application B will be able to treat the user as authenticated without requiring end-user interaction.
The key points from above is that an application can inquire if a user is already authenticated in a non-interactive way (without user intervention). In case of success the application can proceed to use the current user identity and any applicable tokens received. If the response is negative then the application should redirect the user through the hosted login page so that he can authenticate and at the same time start an authenticated session at the idp.
Have in mind that the above approach which centralizes the login, although being the recommended one, implies some possible changes to how applications work. In particular, input of user credentials (when actually needed) would now happen at a central location (hosted login page) instead of directly in the client application.
Another approach that could still allow for an embedded login experience, user credentials input directly in the client application, while still allowing the creation of an authentication session at the idp exist. However, this approach is not recommended and currently has some limitations, for example, embedded login still does not have full support for API authorization features or OIDC compliance.