Configure Single Sign-on for Auth0 Dashboard
Before you start
Subscribe to an Enterprise plan. For more information, read Manage Subscriptions.
Determine whether you're using Public Cloud or Private Cloud. For Private Cloud-related prerequisites to these instructions, see Deploy Private Cloud.
You can configure Auth0 to allow Tenant Members to use your own Enterprise identity provider (IdP) to authenticate to the Auth0 Dashboard through single sign-on (SSO).
How it works
Configuring SSO for the Dashboard requires you to work with Auth0 Support to add an Enterprise connection to the root tenant authority (RTA), which manages the available authentication methods a Tenant Member can use to log in to the Dashboard.
Adding this SSO connection does not restrict Tenant Members from logging in using the existing authentication methods (such as email/password, LinkedIn, Microsoft, GitHub, or Google).
Configuring SSO for the Dashboard also enables SSO for all public Auth0 sites, such as:
Auth0 website (https://auth0.com)
Auth0 Community (https://community.auth0.com)
Auth0 Docs (https://www.auth0.com/docs)
Auth0 Support Center (https://support.auth0.com)
User experience
When an authorized user goes to log in to the Dashboard, they enter their email address for a registered domain (for example, user@example.com
) into the Auth0 Universal Login page, and then are redirected to your IdP to complete authentication.
Limitations
Before you decide to configure SSO for the Dashboard, please consider the restrictions:
SSO cannot be limited to specific tenants.
SSO does not support IdP-initiated authentication flows.
Tenant Member invitations cannot be automated or sent in bulk with the Auth0 Management API.
Tenant Member access cannot be managed by your IdP’s group memberships.
MFA cannot be enforced for all members of a tenant.
Considerations
Full directory access to Dashboard
When you add your IdP as an available connection for Tenant Members to log in on, all of the users in your IdP’s directory are able to access the Dashboard, but only the Tenant Members who have been invited to a given tenant are able to access that tenant.
If a user attempts to access a tenant in the Dashboard that they have not been invited to, they are prompted to complete user profiling and create a new trial tenant. If they create a new trial tenant, it will not be associated with your Enterprise plan.
Residual Tenant Member identities
If a Tenant Member was invited (and had access) to a tenant in the Dashboard using a different identity than the one created on the new connection, they will still—technically—be able to use that identity to access the tenant.
You’ll have to decide if you want to remove their old identity, or keep it as a potential alternative authentication method.
Configure SSO for the Dashboard
Configuring SSO for the Dashboard requires a series of steps shared between you and Auth0 Support.
Share IdP configuration data
Open a ticket with Auth0 Support to share your IdP’s configuration data so they can set up the SSO configuration. Include the following information when you submit your ticket:
Email domain(s) you’d like to associate with the SSO configuration
Name of the IdP
Authentication protocol
Additional IdP-specific information
There are additional configuration steps required depending on the IdP and authentication protocol you’d like to use:
ADFS (SAML)
Create a Relying Party Trust with the following properties:
Property Values Entity ID urn:auth0:auth0:{assignedConnectionName}
Callback endpoint https://auth0.auth0.com/login/callback
Add a claim description for each of the following claims:
Claim Claim identifier Value Name Identifier http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
E-Mail-Addresses
orUser-Principal-Name
Email Address http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
N/A Name http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
N/A Enable the SAML 2.0 endpoint.
Provide Auth0 Support with the following information:
Login endpoint (for example,
https://{yourServer}/adfs/ls
)Signing certificate, or the SAML metadata XML file
Azure AD (OIDC)
Set the Redirect URI type to Web, and the value to
https://auth0.auth0.com/login/callback
.Select Register.
Enable the Implicit Grant for the ID Token.
Add the email claim to the ID Token.
Provide Auth0 Support with the following information:
The application (client) ID
The OIDC metadata endpoint (for example,
https://login. microsoftonline.com/{yourAzureAdTenantId}/v2.0/.well-known/openid-configuration
)
Azure AD (SAML)
Set up single sign-on for SAML with the following properties (you may need to use placeholder values until Auth0 Support can provide you with the SSO connection’s name):
Property Value Identifier (Entity ID) urn:auth0:auth0:{assignedConnectionName}
Reply (ACS) URL https://auth0.auth0.com/login/callback
Sign-on URL https://manage.auth0.com/login?connection={assignedConnectionName}
Leave the Attributes & Claims section - including
email
,Unique User Identifier
, and optionallyname -
unchanged from Azure's suggestions.Provide Auth0 Support with the SAML metadata XML data. You can either:
Share the App Federation Metadata URL (for example,
https://login.microsoftonline.com/{azureAdTenantId}/federationmetadata /2007-06/federationmetadata.xml?appid={appId}
).Download the Federation Metadata XML document and attach it to the ticket.
Google (SAML)
Auth0 supports configuring SSO for the Dashboard with a Google SAML IdP, but it’s recommended that you direct users to log in with the existing Google authentication method.
When a user logs in to the Google SAML IdP, Auth0 creates a new user identity for them (separate from their existing Google user identity), which may be confusing.
If you’d like to set up SSO for the Dashboard with a Google SAML IdP, read Generic IdP (SAML) for instructions.
Okta (SAML)
Create a SAML application with the following properties (you may need to use placeholder values until Auth0 Support can provide you with the SSO connection’s name):
Property Value Entity ID urn:auth0:auth0:{assignedConnectionName}
Callback endpoint (ACS URL) https://auth0.auth0.com/login/callback
Set the Name Identifier to send the email address of the user.
Provide Auth0 Support with the SAML metadata XML data. You can either:
Share the SAML metadata XML URL:
Locate the SAML Signing Certificates section.
Select the Actions menu.
Select View IdP metadata, and then select Copy Link Address. It will have this format:
https://{org}.okta.com/app/{appId}/sso/saml/metadata
.
Download the SAML metadata XML file and attach it to the ticket.
IdP-initiated authentication flows
SSO for the Dashboard does not support IdP-initiated authentication flows. If you want users to be able to select a chiclet to log in to the Dashboard you need to:
Hide the SAML app from users.
Create a Bookmark App that points to
https://manage.auth0.com/login?connection={assignedConnectionName}
. This is the application that users will be able to select to log in.
Make sure you enable both the SAML application and the Bookmark App for the same set of users that can use the application.
OneLogin (SAML)
Create a SAML Test Connector (SP) with the following properties (you may need to use placeholder values until Auth0 Support can provide you with the SSO connection’s name):
Property Value Entity ID urn:auth0:auth0:{assignedConnectionName}
Callback endpoint (ACS URL) https://auth0.auth0.com/login/callback
Login URL https://manage.auth0.com/login?connection={assignedConnectionName}
Provide Auth0 Support with the SAML metadata XML file.
Generic IdP (OIDC)
Register an application (client) with the IdP with the following properties:
Property Value Callback URL https://auth0.auth0.com/login/callback
Provide Auth0 Support with the:
Application (client) ID
Issuer URL or OIDC metadata endpoint (for example,
https://{idpDomain}/[...]/.well-known/openid-configuration
)
Generic IdP (SAML)
Auth0 Support will provide you with the SSO connection's name.
Create a SAML application with the following properties:
Property Value Entity ID urn:auth0:auth0:{assignedConnectionName}
Callback endpoint https://auth0.auth0.com/login/callback
Ensure that the SAML assertions contain the following claims:
Claim Claim identifier Value Name Identifier http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
upn
oremailaddress
Email Address http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
N/A Name http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
N/AA Provide Auth0 Support with either the:
Sign-in URL and signing certificate
SAML metadata XML file
Set up SSO connection
The Auth0 Support team uses the configuration data you provide to complete initial setup of the SSO connection.
Home Realm Discovery (HRD) is not configured during initial setup.
Test SSO connection
When initial setup of the SSO connection is complete, the Auth0 Support team has you test the SSO connection to ensure the configuration data was correct, and that Tenant Members can authenticate on the SSO connection in the manner you’re looking for.
The Auth0 Support team provides you with a direct login URL you can use to prompt authentication for the new SSO connection. For example:
https://manage.auth0.com/login?connection={assignedConnectionName}
Enforce SSO with Auth0 Teams
If you use Auth0 Teams with your Enterprise tenant, you can enforce SSO authentication for the tenants that belong to the Teams account. To learn more about tenant administration and management, read Auth0 Teams.
Open a new browser and enter your Teams account and identifier:
https://accounts.auth0.com/teams/{team-identifier}.
Navigate to the Security page.
Configure the Security Policies by selecting Enforce Single Sign On.
Enable Home Realm Discovery (optional)
If you’re using Universal Login or Classic Login, you can request to enable HRD, so the login page recognizes the domain of the email address the Tenant Member enters, and then directs them to the new SSO connection.
When to enable HRD
If HRD is enabled, Tenant Members that previously used an email/password identity (with an email matching the configured HRD domain) won’t be able to log in through the login page.
Due to this change in behavior, request to enable HRD only after at least some of the current Tenant Members are aware of the change, and that they know that they’ll either:
Receive an invitation to join the tenants under the new identity
Need to re-invite themselves with the new identity
How to bypass HRD
If a Tenant Member needs to log in with their email/password identity, you can provide them with a direct login URL:
https://manage.auth0.com/login?connection=auth0
This URL bypasses HRD, and allows them to log in with their email/password identity.
Example of HRD login behavior
Here’s an example of a list of Tenant Members:
Tenant | Tenant Member | Connection | Affected? |
---|---|---|---|
fabrikam@us |
user1@example.com |
email/password | Yes |
fabrikam@us |
user1@gmail.com |
google-oauth2 | No |
fabrikam@us |
user2@example.com |
github | No |
fabrikam@us |
user3@acme.com |
email/password | No |
fabrikam@us |
user4@example.com |
email/password | Yes |
fabrikam-dev@us |
user5@example.com |
email/password | Yes |
fabrikam-dev@us |
user1@example.com |
email/password | Yes |
If we associate the example.com domain to the new connection, the Tenant Members user1@gmail.com
, user2@example.com
, and user3@acme.com
are able to log in as they have previously, because they use either a social provider, or an email with a unassociated domain.
Alternatively, the Tenant Members user1@example.com
, user4@example.com
, and user5@example.com
are not able to log in as they have previously, because their emails are associated with the domain configured for HRD.
Migrate existing Tenant Members
The process to migrate existing Tenant Members depends on whether you have enabled HRD.
How to migrate with HRD disabled
To migrate Tenant Members with HRD disabled, you need to share the direct login URL for the new SSO connection:
https://manage.auth0.com/login?connection={assignedConnectionName}
Create a new Tenant Member invitation for the Tenant Member.
Instruct the Tenant Member to:
Log in on the new SSO connection by using the direct login URL before accepting the invitation.
Copy and paste the invitation URL they received in the invitation email into the same browser where they logged in on the new SSO connection. Users should not select Create Account.
Accept the invitation.
If the user has invitations for other tenants, they can use them at this time.
How to migrate with HRD enabled
To migrate Tenant members with HRD enabled, you need to follow steps similar to adding Tenant Members:
Create a new Tenant Member invitation for the Tenant Member.
Instruct the Tenant Member to:
Log out of the Dashboard (if they had previously logged in with an old identity).
Open the invitation link in the invitation email they received.
Log in on the new connection.
Accept the invitation.