Value of the Audience Attribute in Auth0 Access Token Requests

When making a request to the /oauth/token endpoint, the audience parameter identifies the target API and determines the format of the returned access token. If the audience parameter is omitted, Auth0 returns an opaque token, and user information must be retrieved via the /userinfo endpoint. Configuring the audience parameter correctly resolves token format and API access issues.

• Auth0
• Access Tokens
• OAuth 2.0
• API Authorization

What Is the Audience Attribute in an Access Token Request?

The audience attribute in the request payload of the /oauth/token call is the unique identifier for the target API Resource Server.

• This attribute value, presented as the aud claim in the access token, defines the token's intended consumer.
• This is typically the resource server (also known as the API identifier in the dashboard) that a client (Application) intends to access.
• The API identifier value should be an absolute URI, but it does not have to be publicly available, as Auth0 will not call the API identifier URI.
• It is possible to make an authorization request without specifying the audience parameter. When the audience is omitted, it defaults to the tenant's GET /userinfo endpoint. Consequently, an opaque token  is issued that can be exchanged for user information

The API identifier in the Dashboard in the respective API's settings tab:

Setting a Custom Default Audience

Configure a default audience in the Auth0 dashboard to apply an audience value automatically when none is specified in the request.

1. Navigate to Applications > APIs in the Auth0 dashboard.
2. Select the target API.
3. Enter the desired default value in the tenant Settings > General tab > Default Audience field.
4. Select Save.

NOTE: Configuring a custom default audience for the tenant automatically appends this audience to all authorization requests across all applications within that tenant. Exercise caution, as this global change might introduce breaking changes for existing applications.

Decoded JWT Example for an Access Token Request

Although the access token is issued to the client or application (azp - authorized party), the client or application is not the intended consumer of the token.

• The client or application acts as the authorized party, represented by the azp claim in the access token.
• The client or application's role is to receive the token for the API identifier, not to consume the token itself.

For example, an application <CLIENT_ID> uses the client credentials flow to request an access token for the audience https://test-api/user. The issued access token includes this audience value in its aud claim.

POST: https://<DOMAIN>/oauth/token

Sample request payload:
{
    "client_id": <CLIENT_ID>,
    "client_secret": <CLIENT_SECRET>,
    "grant_type": "client_credentials",
    "audience": "https://test-api/user"
}

Sample response:
{
    "access_token": "ey...yz",
    "scope": "...",
    "expires_in": 600,
    "token_type": "Bearer"
}

Corresponding access token after decoding the access_token using jwt.io:

"header": {
  ...
},
"payload": {
  "iss": "https://<DOMAIN>/",
  "sub": "CLIENT_ID@clients",
  "aud": "https://test-api/user",
  "gty": "client-credentials",
  "azp": "CLIENT_ID",
  ...
},
"signature": "12...56"

Check out this video: