About Auth0 as IDP

Auth0 is natively supported by Cloudentity as an OIDC Identity Provider, which means that it has a dedicated connection template in Cloudentity for your convenience. Auth0 applications implement the OIDC protocol, providing the proof of user authentication to Cloudentity within an ID Token and Access Token.

The client initiates an OAuth flow with the Authorization Code grant type, requesting the OpenID, E-mail, and Profile scopes, as shown in the diagram below.

1. Client app requests the authorization code from Cloudentity.

2. Cloudentity requests the authorization code from Auth0 IDP.

3. Auth0 authenticates the user and asks for consent to share data with Cloudentity.

4. Auth0 issues the code to Cloudentity after user’s authentication.

5. Cloudentity requests tokens from Auth0 using the provided code.

6. Auth0 issues the tokens to Cloudentity.

7. Optionally, Cloudentity uses the token to pull additional user information - only when the Get user info option is selected in the connector.

8. Cloudentity asks for user consent to share data with the client app, unless the client app is marked as trusted or the requested scopes were already granted for this app.

9. Cloudentity issues the authorization code to the client app.

10. Client app requests the tokens from Cloudentity.

11. Cloudentity issues the tokens to the client app. Cloudentity tokens are minted based on the incoming Auth0 tokens with claims mapped to Cloudentity’s authentication context.

The following steps in the flow are optional:

• Cloudentity only pulls user information if this option is explicitly enabled in the Auth0 connector configuration, as explained later in this document.
• Cloudentity only asks for consent if the client application is not marked as trusted and requests scopes which were not granted previously (or scopes for which the user’s consent has been withdrawn).

Auth0 and SAML

Auth0 applications can also use the SAML protocol, but this integration is not natively supported by Cloudentity yet. If necessary, you can use the generic SAML connector to bind Auth0 apps via SAML.

Prerequisites

You must have an OAuth application (Regular Web Application) registered with Auth0. You will need the basic application information (Domain, Client ID, Client secret) to integrate your application with Cloudentity.

Connect Auth0 in Cloudentity

Basic Configuration

1. In your workspace, go to Authentication » Providers > Create Connection.

2. Select the Auth0 template and click Next.

3. Add the redirect URL from Cloudentity as Callback URLin Auth0.

4. In the Auth0 form, enter the Domain, Client ID, and Client Secret.

   Parameter	Description
   Domain	Auth0 domain where the IDP app is registered, similar to dev-kzv8xwxr.us.auth0.com. Do not include the protocol in the domain.
   Client ID	Client ID of the application registered with Auth0
   Client secret	Secret of the application registered with your Auth0

5. Optionally, enable Authentication context caching.

   Tip

   You can enable the authentication context caching if you wish to store the user’s authentication context locally. If you do, specify the cache Time To Live as well. Learn more by reading Stateful authorization with Cloudentity.

6. Select Save.

   Result

   Your new IDP connection is created. Users can now authenticate via the OIDC-compliant IDP.

Configure Advanced Settings

1. From the Identities > YOUR_IDENTITY > Configuration page, select Advanced settings at the bottom.

2. In the Authentication Method Reference, you can select an authentication method to be written into the amr object returned by the IDP. The amr object is written if it doesn’t exist. If it exists, its values are replaced with the selected item.

3. Optionally, enable the Get user info option.

   Note

   If you enable the Get user info option, the connector calls the Auth0 userinfo endpoint to retrieve additional user attributes.

4. Select Save.

Add custom OIDC IDP attributes

If your IDP returns custom claims outside of the standard OIDC scope, make sure to add them to the IDP connector so that they can be recognized and mapped to the authentication context. Some IDPs (for example Cognito) may require you to set custom attribute permissions first.

1. Go to {{% nav-paths/idps %}} and select an IDP from the list.

2. Open the Attributes page. A standard list of OIDC attributes returned by this IDP appears.

3. Select Add attribute.

4. In Source, select the data source for the custom attribute

   Source	Description
   Access token	Get data from the access token received from the IDP
   ID token	Get data from the ID token received from the IDP
   User info	Get data data returned by the OIDC user info endpoint (note that this must be explicitly enabled on the IDP connector)

5. Fill in the rest of the form.

   Option	Description
   Claim name	Name of your custom attribute matching the incoming IDP claim
   Display name	User-friendly name for the custom attribute
   Data type	Data type matching that of the incoming IDP claim

   Claim names with a . character

   If the incoming attribute has a . character in the name, the dot must be explicitly escaped using \. when defining the IDP attribute. For example, claim name https://example.com/groups must be entered as https://example\.com/groups.

6. Save your changes and proceed to mapping the attributes to the authentication context.

Map IDP Attributes to Authentication Context

If you’ve added custom attributes for an IDP, you need to make sure they are mapped to the {{< product-name acp >}} authentication context. You can do it either from the IDP configuration page (as explained here) or use Data Lineage instead.

Default OIDC/SAML attributes are mapped out of the box.

1. Go to {{% nav-paths/idps %}} and select an IDP from the list.

2. Open the Mappings page. A standard attribute mapping for this IDP appears.

3. Select Add mapping and map any custom IDP attributes to an existing authentication context attribute.

   Note

   If you need to create new authentication context attributes, read the Managing Authentication Context.

4. Optionally, you can enrich authentication context before issuing the token to the client. Attributes returned by the script do not need to be separately mapped to the authentication context.

5. Save your changes. Your mapped custom attributes should now be shared in the ID token issued to your client application, given that the target application requests them (you can check this in Data Lineage).

Connect Extensions to your IDP

1. Go to {{% nav-paths/idps %}} » YOUR_IDP » Extensions.

2. Assign a Post Authentication script to the IDP. This script will be executed upon user authentication via this IDP.

3. Connect your application to the IDP in the Post Authentication application field. Users will be redirected to this application upon authentication via this IDP.

   Feature flag

   Post Authentication applications must be explicitly enabled in your tenant using the custom_apps feature flag.

Test Auth0 IDP

Prerequisite

Your provider is configured as a user-authentication method by your administrator. Demo workspace is available.

Test

1. Open the user portal.

2. Select LOGIN TO DEMO APP.

3. Select your configured IDP and, next, authenticate in IDP.

Result

Cloudentity displays the consent page that lists data scopes to be shared with the application. When you proceed to the application (ALLOW ACCESS), the PII data coming from IDP is delivered through the access token and the ID token generated by Cloudentity.

Read more

For information on granting and managing Cloudentity consents, see Cloudentity OAuth consents.

Related Articles

• Configuring claims for ID tokens and access tokens

• Data lineage

• Setting up authentication context