Problem statement
An Auth0 subscription contains two “production” applications that exist in two separate tenants. Each of these applications has a separate login page within each tenant (i.e. two URLs).
It is proposed that both applications be accessed via a single unified login page, for three reasons:
- To provide users with a single entry point to our products
- For users with access to both products, they can utilize the same login credentials.
- For users that are subscribed to a single product, it provides a method of cross-selling to the other product
This article will explain how to create a single unified login page that can span two tenants.
Solution
Here is one example of how to create a single page that can be used to manage access to multiple applications.
Consider the case where there are two web applications: appA and appB. Each of these exists in a separate tenant:
- App1 in Tenant1
- App2 in Tenant2
For this configuration to work, it will also be necessary to employ an additional tenant:
- Tenant3 will play the role of the Login Tenant
The connections could then be configured as follows:
Tenant 1 <= OIDC or SAML Enterprise connection => Tenant 3
Tenant 2 <= another OIDC or SAML Enterprise connection => Tenant 3
Assuming the app supports OIDC, the apps will explicitly pass the connection parameter to avoid the login widget from appearing from Tenant 1 and Tenant 2.
This could help to implement this use case:
App1 => LOGIN_DOMAIN_APP_1/authorize?connection=CONNECTION_NAME_1&..
App2 => LOGIN_DOMAIN_APP_2/authorize?connection=CONNECTION_NAME_2&..
App1 and App2 are required to use different login domains as they are on different tenants. However, as the connection parameter is passed to /authorize , the tenant will forward it immediately to Tenant3. If there is a session for the user, the user will be logged in immediately.
Alternative options
Other options exist to support variations on the basic use-case.
External Identity Provider
A further option would be to implement an external Identity Provider (IdP) to provision users. This would create a centralized pool of users that could login into tenant applications. When a user attempts to login into an application, the authentication flow requests the identity provider to authenticate the user. This approach is in contrast to having user accounts reside within Auth0 database connections within each tenant. For further information, refer to Identity Providers.
IdP-Initiated Login
Another option might be to employ an IdP-initiated Login. Using this arrangement the end user logs into the IdP and is then presented with a ‘portal’ page that displays a list of applications. This might help with the goal of cross-selling, as it would create awareness of alternative applications that are offered by the business. For more information, refer to Identity-Provider-Initiated-Initiated Single Sign-On.