Overview
When using the Azure AD connection type with Universal Login, users with the matching email domain to the Azure tenant are automatically routed when using Identifier First authentication profiles by home realm discovery (HRD).
- It is assumed that all users on the same email domain as the login domain should be routed to the Azure AD connection as indicated on the connection’s UI:
This article provides a few potential workarounds for disabling HRD to use a different connection, like a database connection for users with the Azure email domain.
Applies To
- Azure AD
- Home Realm Discovery (HRD)
- Identifier First
Cause
Solution
There are a few options for working around this behavior:
- Force Auth0 to use a certain connection by passing a “connection” querystring parameter in /authorize requests.
- This is useful for testing purposes or hardcoding login buttons on an application to use a certain connection
- For example, to force to use a specific database type connection, use:
https://<YOUR_TENANT_DOMAIN>/authorize?connection=<DATABASE_CONNECTION_NAME_HERE>&client_id=<rest of normal params here...>
-
Set up the Azure AD connection as a SAML or Enterprise OIDC connection instead. This would only use HRD when the email matched the connection’s Identity Provider Domains list on the relevant connection.
- See the following guide for setting up Azure AD with a SAML connection:
- And for setting up with an OIDC connection:
-
Change to use Identifier + Password authentication profile.
- In this setup, the enterprise connections need to be rendered as buttons. Submitting a username and password combination would be checked against the enabled database connection.
- See Step 4 here for enabling connections as buttons in New Universal Login: Define Home Realm Discovery identity providers
-
Create a fully custom login page using, for example, the auth0.js SDK that can perform additional logic before submitting the login request to a particular connection based on the use case