Docs

Authenticate using OpenIDConnect to another Auth0 Tenant (Deprecated)

This solution has been deprecated because it requires the use of a legacy version of the Auth0 User Profile.

You can use an application on one Auth0 tenant (referred to below as the OIDC Provider tenant) as an identity provider in another Auth0 tenant (the Relying Party tenant).

Configure the OIDC Provider Auth0 Tenant

  1. Create an Application or edit an existing one. Set the application type to Regular Web App.
  2. Take note of your application's Client ID and Client Secret. You will need these to create the connection in the Relying Party tenant.
  3. Add the Relying Party tenant's login callback to the list of Allowed Callback URLs: https://YOUR_DOMAIN/login/callback

Find your Auth0 domain name for redirects

If your Auth0 domain name is not shown above and you are not using our custom domains feature, your domain name is your tenant name, plus .auth0.com. For example, if your tenant name were exampleco-enterprises, your Auth0 domain name would be exampleco-enterprises.auth0.com and your redirect URI would be https://exampleco-enterprises.auth0.com/login/callback.

If you are using custom domains, your redirect URI will have the following format: https://<YOUR CUSTOM DOMAIN>/login/callback.

  1. Make sure that the OIDC-Conformant toggle in the OAuth tab under the application's Advance Settings is turned off.

  2. Make sure that the tenant has the Legacy User Profile toggle enabled under the Migrations section of the Tenant Advanced Settings. If you don't see this toggle for your tenant, please open a support case to request this feature to be enabled.

Configure the Relying Party Auth0 Tenant

The Auth0-to-Auth0 connection is not yet supported in the Dashboard. You need to create the connection using the Create a connection endpoint, which will require an Management API V2 token with create:connections scope.

Here is a sample request:

with the auth0-oidc-connection.json file containing:

The required parameters for this connection are:

Parameter Description
name How the connection will be referenced in Auth0 or in your app
strategy Defines the protocol implemented by the provider. This should always be auth0-oidc
options.client_id The clientID of the target Application in the OIDC Provider Auth0 tenant
options.client_secret The clientSecret of the target Application in the OIDC Provider Auth0 tenant
options.domain The domain of the OIDC Provider Auth0 tenant
options.scope
Optional
The scope parameters for which you wish to request consent (such as profile, identities, and so on)
enabled_clients
Optional
An array containing the identifiers of the applications for which the connection is to be enabled. If the array is empty or the property is not specified, no applications are enabled

Use the Auth0 connection

You can use any of the standard Auth0 mechanisms (such as direct links, Auth0 Lock, auth0.js, and so on) to log in a user with the auth0-oidc connection.

A direct link would look like:

To add a custom connection in Lock, you can add a custom button as described in Adding a new UI element using JavaScript and use the direct link as the button href.

The user will be redirected to the built-in login page of the OIDC Provider Auth0 tenant where they can choose their identity provider (from the enabled connections of the target Application) and enter their credentials.

The resulting profile

Once the user is authenticated, the resulting profile will contain the Normalized User Profile fields. For example:

Note that the generated user_id has the following format:

auth0-oidc|YOUR_AUTH0_CONNECTION_NAME|THE_OIDC_PROVIDER_AUTH0_CONNECTION|THE_OIDC_PROVIDER_USER_ID

The Access Token is the JWT of the user in the OIDC Provider Auth0 connection. If you decode it, you will see all the properties that were requested in the scope of the auth0-oidc connection. For example, for scope=openid email will return: