JSON Web Key Set

Dynamic Client Registration

Dynamic Client Registration enables you to register third-party applications dynamically.

This feature is based on the OpenID Connect Dynamic Client Registration specification and in this article we will see how you can enable and use it.

Keep reading

Enable dynamic registration

Auth0 supports Open Dynamic Registration, which means that if you enable this feature, anyone will be able to create applications in your tenant without a token.

By default, the feature is disabled for all tenants. To change this, you have to set the enable_dynamic_client_registration flag to true in your tenant's settings.

This can be done by enabling the OIDC Dynamic Application Registration toggle on your tenant's Advanced Settings page.

Alternatively, you can update this flag using the Update tenant settings endpoint.

You need to update the API2_ACCESS_TOKEN with a valid token with the JSON Web Token (JWT)scope update:tenant_settings. See Access Tokens for the Management API for details on how to do so.

Use dynamic registration

In this section we will see how you can dynamically register and configure an application.

Register your application

To dynamically register an application with Auth0, you need to send an HTTP POST message to the Application Registration endpoint: https://YOUR_DOMAIN/oidc/register. Note that Auth0 supports Open Dynamic Registration, which means that the endpoint will accept a registration request without an Access Token.

To create an application with the name My Dynamic application and the callback URLs and, use the following snippet.


  • client_name: The name of the Dynamic Application to be created
  • redirect_uris (required): An array of URLs that Auth0 will deem valid to call at the end of an authentication flow

Optionally, you can set a value for token_endpoint_auth_method, which can be none or client_secret_post (default value).

The response includes the basic application information.


  • client_id: Unique client identifier. This is the ID you will use while configuring your apps to use Auth0. It is generated by the system and it cannot be modified.
  • client_secret: Alphanumeric 64-bit client secret. This value is used by applications to authenticate to the token endpoint and for signing and validating ID Tokens.
  • client_secret_expires_at: Time at which the client_secret will expire. For Auth0 this value will always be zero (0) which means that the application never expires.

Make a note of the Client ID and Secret, as these are the most important pieces for executing authentication and authorization flows.

Also, keep in mind that third-party developers are not allowed to modify the application settings. In case this is necessary, they need to contact the tenant owner with their request.

Configure your application

Now that you have a Client ID and Secret, you can configure your application to authenticate users with Auth0.

We will go through a simple example, that shows how to call an API from a client-side web app, using the Implicit Flow. For a list of tutorials on how to authenticate and authorize users, based on your application type, see the API Authorization page.

First, you need to configure your application to send the user to the authorization URL:


  • audience (optional): The target API for which the Application is requesting access on behalf of the user. Set this parameter if you need API access.

  • scope (optional): The scopes which you want to request authorization for. These must be separated by a space. You can request any of the standard OIDC scopes about users, such as profile and email, custom claims that must conform to a namespaced format (see panel below for more info), or any scopes supported by the target API (for example, read:contacts). Set this parameter if you need API access.

    Custom claims namespaced format

    In order to add custom claims to ID Tokens or Access Tokens, they must conform to a namespaced format to avoid possible collisions with standard OpenID Connect claims. For example, if you choose the namespace and you want to add a custom claim named myclaim, you would name the claim, instead of myclaim.

  • response_type: The response type. For Implicit Grant you can either use token or id_token token. This will specify the type of token you will receive at the end of the flow. Use token to get only an Access Token, or id_token token to get both an ID Token and an Access Token.

  • client_id: Your application's Client ID.

  • redirect_uri: The URL to which the Authorization Server (Auth0) will redirect the User Agent (Browser) after authorization has been granted by the User. The Access Token (and optionally an ID Token) will be available in the hash fragment of this URL. This URL must be specified as a valid callback URL under the Application Settings of your application.

  • state: An opaque value the applications add to the initial request that the authorization server includes when redirecting the back to the application. This value must be used by the application to prevent CSRF attacks.

  • nonce: A string value which will be included in the ID Token response from Auth0, used to prevent token replay attacks. It is required for response_type=id_token token.

For example:

This call will redirect the user to Auth0, and upon successful authentication, back to your application (specifically to the redirect_uri).

If you need API access, then following the authentication, you need to extract the Access Token from the hash fragment of the URL, and use it to make calls to the API, by passing it as a Bearer token in the Authorization header of the HTTP request.