I have got the following use case:
- two single page applications made with Angular4+.
- for simplicity call them A and B.
- only A will have a login screen.
So if you come to B and are not authenticated you should be redirected to A’s login screen. When you login on A’s login screen you should be redirected to B again and logged in.
Both the applications have SSO implemented based on https://github.com/auth0-samples/auth0-angular-samples/tree/master/06-Single-Sign-On
The struggle I have is that if I go to B and redirect to A’s login screen and try to login and redirect to B again logged in I am stuck. Because A login’s screen thinks I want to login in application A rather go back to application B.
The goal you describe does not seem the most correct. A client application should delegate authentication to an identity provider/authorization server so if B is redirecting to A for authentication purposes this means that A would need to be treated as an identity provider/authorization server and support all the complexity that would come with that.
For a SSO use case between two applications the flow should be the following:
- The end-user accesses application
1 which detects that there’s no local session nor a session in the associated IdP so it redirects the end-user to the IdP.
- The IdP does not have a session so it needs to authenticate the end-user which translates to displaying the necessary interface to complete the authentication.
- The end-user completes the authentication step.
- The IdP has the required context to know this authentication was originally requested by application
1 so it redirects the end-user to the associated application and sends along a token/assertion that proves the user identity.
- The application
1 receives the token/assertion, validates it and proceeds to consider the user as authenticated.
- (…)
- The end-user then accesses application
2 which detects that there’s no local session, but does detect that there’s an existing session at the IdP so it proceeds to communicate with the IdP in a way that it’s transparent for the end-user (aka application 2 requests and receives a token/assertion that proves the user identity without the user having to provide any sort of interaction).
- The application
2 validates the received token/assertion and proceeds to consider the user as authenticated.
From a quick look at the linked sample code, the above is what’s implemented in the linked sample and it’s indeed the recommended flow. In this flow the IdP would be your Auth0 tenant and the common login page that it’s used for authentication by both application would be the hosted login page (which you can customize). All the requirements about this login page knowing to which application the user should be redirected after completing the authentication step is handled by the Auth0 service as part of the fact that it supports the associated protocols (OpenID Connect and OAuth2) that define how those redirects happen.
In conclusion, the common login page should be the hosted login page.