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.
Enable dynamic registration
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 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
https://application.example.com/callback2, 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
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_secretwill expire. For Auth0 this value will always be zero (
0) which means that the application never expires.
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
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
https://foo.com/and you want to add a custom claim named
myclaim, you would name the claim
https://foo.com/myclaim, instead of
response_type: The response type. For Implicit Grant you can either use
id_token token. This will specify the type of token you will receive at the end of the flow. Use
tokento get only an Access Token, or
id_token tokento 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
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.