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, [e-mail]) 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.

When users attempt to access a tenant in the Dashboard without an invitation, the system denies the operation. If users do not belong to any tenants, the system prompts them to complete their user profile and create a new trial tenant. Creating a new trial tenant does not associate it 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)

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

Azure AD (OIDC)

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)

Azure AD (SAML)

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. Leave the Attributes & Claims section - including email, Unique User Identifier, and optionally name - unchanged from Azure’s suggestions.

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

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.

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:

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.

OneLogin (SAML)

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.

Generic IdP (OIDC)

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

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

2. Add the email claim to the ID Token.

3. Provide Auth0 Support with the:

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

Auth0 Support will use Implicit Mode with Form Post flow, if available. If your IdP does not support this, then you’ll need to provide them with your application’s client secret.

Generic IdP (SAML)

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

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.

1. Open a new browser and enter your Teams account and identifier: https://accounts.auth0.com/teams/{team-identifier}.

   You can get the Teams identifier in the URL or the Teams Settings.

2. Navigate to the Security page.

3. 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, and HRD is only compatible with email identifiers.

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	[e-mail]	email/password	Yes
fabrikam@us	[e-mail]	google-oauth2	No
fabrikam@us	[e-mail]	github	No
fabrikam@us	[e-mail]	email/password	No
fabrikam@us	[e-mail]	email/password	Yes
fabrikam-dev@us	[e-mail]	email/password	Yes
fabrikam-dev@us	[e-mail]	email/password	Yes

If we associate the example.com domain to the new connection, the Tenant Members [e-mail], [e-mail], and [e-mail] 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 [e-mail], [e-mail], and [e-mail] 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}

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 see a profile enrichment page (at https://auth.com/profile). Do not fill out any fields or select Next. Instead, follow the next step.

   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. Users should not select Create Account.

   3. Accept the invitation.

   4. 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:

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

      If this is the first invitation they are accepting, they may see a “Create a new tenant” or “Create a new account” page. Do not select Next. Instead, follow the next step.

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

   3. Log in on the new connection.

   4. Accept the invitation.