Hi @theja
Welcome to the Auth0 Community!
You are migrating from Auth0 Classic Login to Auth0 Universal Login with Identifier-First authentication to move Home Realm Discovery (HRD) from the client side to the server side, addressing security concerns about exposing domain and connection information. You need to support two complex connection scenarios: (1) the same email address existing in both Enterprise and Database connections, with user selection between them, and (2) multiple Database connections in your JP tenant. You are asking whether Universal Login can support both scenarios while keeping connection selection server-side.
Auth0 Universal Login with Identifier-First authentication can support server-side HRD and handle complex connection routing. However, your two scenarios require custom configuration beyond standard Universal Login setup. Scenario 1 (same email across Enterprise and Database) requires custom authentication rules or post-login actions to present a connection selection UI. Scenario 2 is supported within the default context of the Universal Login. Both scenarios are achievable but require implementation beyond the default Universal Login behavior.
[Root Cause]
Auth0 Universal Login's default Identifier-First behavior assumes a one-to-one mapping between email domain and connection. When a user enters their email, Auth0 uses Home Realm Discovery to route them to the appropriate connection based on domain rules. However, your scenarios violate this assumption:
- Scenario 1: The same email domain (company.com) maps to multiple connections (Enterprise O365 and Database custom-db)
Scenario 1: Same Email Address in Enterprise and Database Connections
Current Limitation:
By default, Universal Login with Identifier-First cannot present a connection selection UI when the same email matches multiple connections. HRD is designed to route based on email domain to a single connection. If both an Enterprise connection and a Database connection are enabled for the same domain, Auth0 will prioritize the Enterprise connection and route the user there automatically.
Recommended Approach:
To support user selection between Enterprise and Database connections for the same email, implement one of these solutions:
Option 1: Use the connection Parameter in the Authorization Request (Recommended)
Your application (not Universal Login) determines which connection the user should use, then passes the connection name in the /authorize request:
- Create a pre-login page in your application (before redirecting to Auth0) where users select their authentication method (e.g., "Log in with O365" or "Log in with Username/Password")
- Pass the connection parameter in the authorization request:
- For Enterprise:
https://your-domain/authorize?client_id=...&connection=O365&login_hint=user@company.com
- For Database:
https://your-domain/authorize?client_id=...&connection=custom-db&login_hint=user@company.com
- When the connection parameter is specified, Universal Login will skip HRD and route directly to that connection, bypassing the identifier-first prompt
Advantage: Connection selection is handled server-side (in your application logic), and users never see all available connections.
Disadvantage: Requires a custom pre-login page outside of Universal Login.
Option 2: Use Post-Login Actions to Implement Custom HRD Logic
Auth0 Post-Login Actions allow you to run custom code after a user enters their email but before they are routed to a connection:
- Enable Identifier-First in Universal Login (standard setup)
- Create a Post-Login Action that:
- Checks if the user's email matches multiple connections
- If yes, redirect the user to a custom connection selection page (hosted by your application)
- If no, allow normal HRD routing
- Your custom page presents the user with connection options and redirects back to Auth0 with the appropriate connection parameter
Advantage: Keeps the flow within Auth0 and allows server-side logic to determine routing.
Disadvantage: Requires custom code and a custom connection selection page.
Scenario 2: Multiple Database Connections in JP Tenant
Current Limitation:
By using the Get User scrips in the context of a custom database connection, you are able to make external calls/queries to multiple external user storages. This is not recommended due to the efficiency of the approach. If you are talking about having two different Database connections each with a custom db, Universal Login does not automatically distinguish between multiple Database connections. By default, it will authenticate against the first enabled Database connection. If you have two Database connections (custom-db1 and custom-db2), Universal Login cannot automatically route users to the correct one based on email address alone.
Recommended Approach:
Use the connection Parameter to Specify the Database Connection
- Your application determines which Database connection the user should use (based on your business logic: Customer Login → custom-db1, Service User Login → custom-db2)
- Pass the connection parameter in the
/authorize request:
- For Customer Login:
https://your-domain/authorize?client_id=...&connection=custom-db1
- For Service User Login:
https://your-domain/authorize?client_id=...&connection=custom-db2
- Universal Login will authenticate against the specified Database connection
Implementation Steps:
- Create a connection selection page in your application where users choose between "Customer Login" and "Service User Login"
- Based on the user's selection, construct the authorization URL with the appropriate connection parameter
- Redirect the user to Auth0 with the connection parameter
- Universal Login will present the username/password prompt for the selected Database connection
Alternative: Use a Custom Database Connection with Logic
If you want to consolidate the two Database connections:
- Create a single Custom Database connection that implements your own authentication logic
- In the Custom Database login script, check the username/email against both custom-db1 and custom-db2
- Authenticate the user against the appropriate database based on your business rules
- Return the user profile to Auth0
Advantage: Single connection to manage; all logic is server-side.
Disadvantage: Requires custom code and maintenance of the Custom Database connection.
Comprehensive Solution: Combining Both Scenarios
To support all three regions (US, EU, JP) with your complex connection requirements:
- For US and EU (Scenario 1):
- Create a pre-login page in your application
- Users select "Enterprise Login" or "Database Login"
- Pass the appropriate connection parameter to Auth0
- Universal Login authenticates against the selected connection
- For JP (Scenario 2):
- Create a pre-login page in your application
- Users select "Customer Login" or "Service User Login"
- Pass the appropriate Database connection parameter to Auth0
- Universal Login authenticates against the selected connection
- Security Benefits:
- Connection information is not exposed to the client
- Users only see relevant authentication options
- Server-side logic determines routing
- No need to display thousands of connection buttons
Implementation Architecture:
User → Your Application (Pre-Login Page) → User selects authentication method → Your application determines connection → Your application redirects to Auth0 /authorize with connection parameter → Universal Login (Identifier-First) → Auth0 routes to specified connection → User authenticates → Auth0 returns tokens to your application
We hope this guidance helps you design a secure and scalable authentication solution for your multi-region deployment. Please follow up if you need further assistance with implementation details.
Kind Regards,
Nik