Configure Single Sign-on for Auth0 Dashboard

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).

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)

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.

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.

• Tenant Members cannot be forced to use a specific authentication method.

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.

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.

Configuring SSO for the Dashboard requires a series of steps shared between you and Auth0 Support.

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:

1. 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

2. 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 or User-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

3. Enable the SAML 2.0 endpoint.

4. Provide Auth0 Support with the following information:

   • Login endpoint (for example, https://{yourServer}/adfs/ls)

   • Signing certificate, or the SAML metadata XML file

1. Create a new App registration.

2. Set the Redirect URI type to Web, and the value to https://auth0.auth0.com/login/callback.

3. Select Register.

4. Enable the Implicit Grant for the ID Token.

5. Add the email claim to the ID Token.

6. 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)

1. Create a new Enterprise Application.

2. 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}

3. 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.

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.

1. 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

2. Set the Name Identifier to send the email address of the user.

3. Provide Auth0 Support with the SAML metadata XML data. You can either:

   • Share the SAML metadata XML URL:

     1. Locate the SAML Signing Certificates section.

     2. Select the Actions menu.

     3. 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.

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: 

1. Hide the SAML app from users.

2. 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.

1. 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}

2. Provide Auth0 Support with the SAML metadata XML file.

1. Register an application (client) with the IdP with the following properties:

   Property	Value
   Callback URL	https://auth0.auth0.com/login/callback

2. Provide Auth0 Support with the:

   • Application (client) ID

   • Issuer URL or OIDC metadata endpoint (for example, https://{idpDomain}/[...]/.well-known/openid-configuration)

1. Auth0 Support will provide you with the SSO connection's name.

2. Create a SAML application with the following properties:

   Property	Value
   Entity ID	urn:auth0:auth0:{assignedConnectionName}
   Callback endpoint	https://auth0.auth0.com/login/callback

3. 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 or emailaddress
   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

4. Provide Auth0 Support with either the:

   • Sign-in URL and signing certificate

   • SAML metadata XML file

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.

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}

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.

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

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.

Here’s an example of a list of Tenant Members:

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.

The process to migrate existing Tenant Members depends on whether you have enabled HRD.

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} 

1. Create a new Tenant Member invitation for the Tenant Member.

2. Instruct the Tenant Member to:

   1. Log in on the new SSO connection by using the direct login URL before accepting the invitation. If this is the first time they are logging in on the new SSO connection, they may need to complete user profiling.

   2. 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.

   3. Accept the invitation.

To migrate Tenant members with HRD enabled, you need to follow steps similar to adding Tenant Members:

1. Create a new Tenant Member invitation for the Tenant Member.

2. Instruct the Tenant Member to:

   1. Log out of the Dashboard (if they had previously logged in with an old identity).

   2. Open the invitation link in the invitation email they received.

   3. Log in on the new connection.

   4. Accept the invitation.

When a Tenant Member logs in to the new SSO connection for the first time, they'll see a form where they need to specify their type of responsibilities.

Instruct the Tenant Member to:

1. Select Yes, Coding.

2. Select I need advanced settings.

3. Select Next, and then continue to the next screen.

   

4. Paste the invitation link they received in the invitation email.

5. Accept the invitation.