You can dynamically register third-party applications for your tenant. This feature is based on the OpenID Connect Dynamic Client Registration specification.

​
Enable dynamic client 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, dynamic application registration 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. To do so, go to Dashboard > Settings > Advanced and enable the OIDC Dynamic Application Registration. Alternatively, you can update this flag using the /Tenant/patch_settings endpoint. 
curl --request PATCH \
--url 'https://{yourDomain}/api/v2/tenants/settings' \
--header 'authorization: Bearer API2_ACCESS_TOKEN' \
--header 'cache-control: no-cache' \
--header 'content-type: application/json' \
--data '{ "flags": { "enable_dynamic_client_registration": true } }'
You need to update the API2_ACCESS_TOKEN with a valid token with the scope update:tenant_settings. To learn more, read Management API Access Tokens.

​
Use dynamic client 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://{yourDomain}/oidc/register. Note that Auth0 supports Open Dynamic Registration, which means that the endpoint will accept a registration request without an . To create an application with the name My Dynamic application and the callback URLs https://application.example.com/callback and https://application.example.com/callback2, use the following snippet: 
curl --request POST \
--url 'https://{yourDomain}/oidc/register' \
--header 'content-type: application/json' \
--data '{"client_name":"My Dynamic Application","redirect_uris": ["https://application.example.com/callback", "https://application.example.com/callback2"]}'
Where:
  • 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). Use token_endpoint_auth_method: none in the request payload if creating a SPA. The response includes the basic application information. 
HTTP/1.1 201 Created
Content-Type: application/json
{
  "client_name": "My Dynamic Application",
  "client_id": "8SXWY6j3afl2CP5ntwEOpMdPxxy49Gt2",
  "client_secret": "Q5O...33P",
  "redirect_uris": [
    "https://application.example.com/callback",
    "https://application.example.com/callback2"
  ],
  "client_secret_expires_at": 0
}
Where:
  • 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 . This value is used by applications to authenticate to the Authentication API /token and for signing and validating .
  • 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 and client secret, as these are the most important pieces for executing authentication and . To learn more, read 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. First, you need to configure your application to send the user to the authorization URL: 
https://{yourDomain}/authorize?
  audience={API_AUDIENCE}&
  scope={SCOPE}&
  response_type={RESPONSE_TYPE}&
  client_id={yourClientId}&
  redirect_uri={https://yourApp/callback}&
  nonce={NONCE}
  state={OPAQUE_VALUE}
Where:
  • (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 for which you want to request authorization. These must be separated by a space. You can request any of the standard OIDC scopes for users, such as profile and email, custom claims that must conform to a namespaced format, or any scopes supported by the target API (for example, read:contacts). Set this parameter if you need API access. To learn more, read API Scopes.
  • 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 (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.
  • : A string value that 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: 
<a href="https://{yourDomain}/authorize?scope=appointments%20contacts&audience=appointments:api&response_type=id_token%20token&client_id={yourClientId}&redirect_uri={https://yourApp/callback}">
  Sign In
</a>
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.

​
Learn more