APIs Overview

Heads up! As part of our efforts to improve security and standards-based interoperability, we have implemented several new features in our authentication flows and made changes to existing ones. For an overview of these changes, and details on how you adopt them, refer to Introducing OIDC Conformant Authentication.


An API is an entity that represents an external resource, capable of accepting and responding to protected resource requests made by applications. At the OAuth2 spec an API maps to the Resource Server.

When an application wants to access an API's protected resources it must provide an Access Token. The same Access Token can be used to access the API's resources without having to authenticate again, until it expires.

Each API has a set of defined permissions. Applications can request a subset of those defined permissions when they execute the authorization flow, and include them in the Access Token as part of the scope request parameter.

For example, an API that holds a user's appointments, may accept two different levels of authorization: read only (scope read:appointments) or write (scope write:appointments). When an application asks the API to list a user's appointments, then the Access Token should contain the read:appointments scope. In order to edit an existing appointment or create a new one, the Access Token should contain the write:appointments scope.

For more information on tokens please refer to: Tokens used by Auth0.

How to configure an API in Auth0

Click on the APIs menu option on the left.

The API tab will already have one API created automatically, the Auth0 Management API. For more details on the features of the Management API and its available endpoints, refer to: Management API.

Click the + Create API button.

Create a new API

You need to provide the following information for your API:

  • Name: a friendly name for the API. Does not affect any functionality.

  • Identifier: a unique identifier for the API. Auth0 recommends using a URL. Auth0 does differentiate between URLs that include the last forward slash. For example, and are two different identifiers. The URL does not have to be a publicly available URL. Auth0 will not call your API. This value cannot be modified afterwards.

  • Signing Algorithm: the algorithm to sign the tokens with. The available values are HS256 and RS256. When selecting RS256 the token will be signed with the tenant's private key. For more details on the signing algorithms go to the Signing Algorithms paragraph.

Fill in the required information and click the Create button.

Once you do so you will be navigated to the Quick Start of your API. Here you can find details on the implementation changes you have to do to your API, which basically consists of choosing a JWT library from a predefined list and configuring this library to validate the Access Tokens in your API.

API Quick Starts

The other available views for your API are:

  • Settings: lists the settings for your API. Some are editable. Here you can change the token expiration time and enable offline access (this way Auth0 will allow your applications to ask for Refresh Tokens for this API). For details refer to the API Settings paragraph.

  • Scopes: here you can define the scopes for this API, by setting a name and a description.

  • Machine to Machine Applications: lists all applications for which the Client Credentials grant is enabled. By default, this grant is *enabled for Regular Web Applications and Machine to Machine Applications. You can authorize any of these applications to request Access Tokens for your API. Optionally, you can select a subset of the defined scopes to limit your authorized application's access.

  • Test: from this view, you can execute a sample Client Credentials flow with any of your authorized applications to check that everything is working as expected.

API Settings

Click on the Settings tab of your API to review the available settings:

  • Id: A unique alphanumeric string generated by Auth0. The information is read only and you will only need it if you will be working directly with Auth0's Management API Resource Servers endpoints.

  • Name: A friendly name for the API. Does not affect any functionality. The following characters are not allowed: < >.

  • Identifier: A unique identifier for your API. This value is set upon API creation and cannot be modified afterwards. We recommend using a URL but note that this doesn't have to be a publicly available URL, Auth0 will not call your API at all.

  • Token Expiration (Seconds): The amount of time (in seconds) before the Auth0 Access Token expires. The default value is 86400 seconds (24 hours). The maximum value you can set is 2592000 seconds (30 days).

  • Allow Skipping User Consent: When a first party application requests authorized access against an API with the Allow Skipping User Consent flag set, the User Consent dialog will not be shown to the final user. Note that if the hostname of your application's callbackURL is localhost or the consent dialog will always be displayed.

  • Allow Offline Access: If this setting is enabled, Auth0 will allow applications to ask for Refresh Tokens for this API.

  • Signing Algorithm: The algorithm to sign the tokens with. The available values are HS256 and RS256. When selecting RS256 (recommended) the token will be signed with the tenant's private key. This value is set upon API creation and cannot be modified afterwards. For more details on the signing algorithms see the Signing Algorithms paragraph below.

Signing Algorithms

When you create an API you have to select the algorithm your tokens will be signed with. The signature is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn't changed along the way.

The signature is part of a JWT. If you are not familiar with the JWT structure please refer to: JSON Web Tokens (JWTs) in Auth0.

To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that. That algorithm, which is part of the JWT header, is the one you select for your API: HS256 or RS256.

  • RS256 is an asymmetric algorithm which means that there are two keys: one public and one private (secret). Auth0 has the secret key, which is used to generate the signature, and the consumer of the JWT has the public key, which is used to validate the signature.

  • HS256 is a symmetric algorithm which means that there is only one secret key, shared between the two parties. The same key is used both to generate the signature and to validate it. Special care should be taken in order for the key to remain confidential.

The most secure practice, and our recommendation, is to use RS256. Some of the reasons are:

  • With RS256 you are sure that only the holder of the private key (Auth0) can sign tokens, while anyone can check if the token is valid using the public key.

  • Under HS256, if the secret key is compromised (e.g. by the application) you would have to re-deploy the API with the new secret.

  • With RS256 you can request a token that is valid for multiple audiences.

  • With RS256 you can implement key rotation without having to re-deploy the API with the new secret.

Verify an RS256 signed token

Go to Dashboard > Applications. Open the Settings of your applications, scroll down and open Advanced Settings. Open the Certificates tab and you will find the Public Key in the Signing Certificate field.

If you want to use the Public Key to verify a JWT signature on, you can copy the Public Key and paste it in the Public Key or Certificate field under the Verify Signature section on the website.

If you want to verify the signature of a token from one of your applications, we recommend that you get the Public Key from your tenant's JSON Web Key Set (JWKS). Your tenant's JWKS is https://YOUR_DOMAIN/.well-known/jwks.json.

For a more detailed overview of the JWT signing algorithms refer to: JSON Web Token (JWT) Signing Algorithms Overview.

Keep Reading