> ## Documentation Index
> Fetch the complete documentation index at: https://docs-staging-docs-5625.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Compare Auth0 and the JSON Web Token Profile specification access token profiles, including differences in the claims format and how to configure the profile for your API.

# Access Token Profiles

<Tooltip tip="Access Token: Authorization credential, in the form of an opaque string or JWT, used to access an API." cta="View Glossary" href="/docs/glossary?term=Access+token">Access token</Tooltip> profiles define the format and claims of access tokens issued for an API. Auth0 supports the following access token profiles, also known as token dialects:

* Auth0 token profile, or the default access token profile
* RFC 9068 token profile, or the access token profile that follows the [IETF JWT Profile for OAuth 2.0 Access Tokens (RFC 9068)](https://datatracker.ietf.org/doc/html/rfc9068)

| Token Profile | Description | Token Dialect |
| - | - | - |
| Auth0 token profile | The default token profile. Issues access tokens formatted as a [JSON Web Token (JWT)](/docs/secure/tokens/json-web-tokens). | The Auth0 token profile is associated with two token dialects:<ul><li>`access_token`</li><li>`access_token_authz`, or the `access_token` profile with the `permissions` claim included</li></ul> |
| RFC 9068 token profile | Issues access tokens formatted as a JSON Web Token (JWT) following the [IETF standard](https://datatracker.ietf.org/doc/html/rfc9068) for encoding OAuth 2.0 Access Tokens in JWT format. | The RFC 9068 token profile is associated with two token dialects:<ul><li>`rfc9068_profile`</li><li>`rfc9068_profile_authz`, or the `rfc9068_profile` profile with the `permissions` claim included</li></ul> |

While both access token profiles issue <Tooltip tip="JSON Web Token (JWT): Standard ID Token format (and often Access Token format) used to represent claims securely between two parties." cta="View Glossary" href="/docs/glossary?term=JWTs">JWTs</Tooltip>, the JWTs have [different token formats](#token-profile-differences). Both access token profiles can enable [Role-Based Access Control (RBAC)](/docs/get-started/apis/enable-role-based-access-control-for-apis) and add the permissions claim to the access token.

To configure the access token profile for an API, read [Configure Access Token Profile](/docs/get-started/apis/configure-access-token-profile).

### Auth0 profile sample token

```json lines theme={null}
{
  "iss": "https://my-domain.auth0.com/",
  "sub": "auth0|123456",
  "aud": [
    "https://example.com/health-api",
    "https://my-domain.auth0.com/userinfo"
  ],
  "azp": "my_client_id",
  "exp": 1311281970,
  "iat": 1311280970,
  "scope": "openid profile read:patients read:admin",
  "my_custom_claim": "my_custom_value"
}
```

### RFC 9068 profile sample token

```json lines theme={null}
{
  "iss": "https://my-domain.auth0.com/",
  "sub": "auth0|123456",
  "aud": [
    "https://example.com/health-api",
    "https://my-domain.auth0.com/userinfo"
  ],
  "client_id": "my_client_id",
  "exp": 1311281970,
  "iat": 1311280970,
  "jti":"73WakrfVbNJBaAmhQtEeDv",
  "scope": "openid profile read:patients read:admin",
  "my_custom_claim": "my_custom_value"
}
```

## Token profile differences

The Auth0 profile and RFC 9068 profile issue JWTs that have different token formats. The main differences are:

* The RFC 9068 profile incorporates the `jti` claim, providing a unique identifier for the JWT.
* The Auth0 profile uses the `azp` claim to represent the <Tooltip tip="Client ID: Identification value given to your registered resource from Auth0." cta="View Glossary" href="/docs/glossary?term=client+ID">client ID</Tooltip> whereas the RFC 9068 profile uses the `client_id` claim.
* The RFC 9068 profile does not use the `gty` claim, which is an Auth0-specific claim that represents the authentication flow.

### Header

| Data | RFC 9068 Profile | Auth0 Profile |
| - | - | - |
| `type` | `at+jwt` | `JWT` |
| `alg` | Signing algorithm, for example, `RS256` | Signing algorithm, for example, `RS256` |

### Claims

<Note>
  When Agents as Principal is enabled for your tenant and agent subject claims are enabled for your API, access tokens can include additional identity claims (`sub_profile`, `client_profile`, and `act`) and an adjusted `sub` value. These claims are added to the access token only; ID tokens are not affected. To learn more, read [Agent identity in tokens](/docs/ai-agents-mcp/agents-as-principal/agent-identity-in-tokens).
</Note>

| Claim | Description | Present in RFC 9068 Profile | Present in Auth0 Profile | Sample Claim |
| - | - | - | - | - |
| `iss` | Issuer identifier for the Auth0 tenant issuing the access token. | Yes | Yes | Tenant domain: `https://tenant.auth0.com/` |
| `sub` | The subject claim indicates which user or application the access token was issued for:<br />- For grants where an end user is involved (e.g., Authorization Code Flow), the `sub` claim is the `user_id`.<br />- For Machine-to-Machine apps using Client Credentials (no end user), the `sub` claim is a unique identifier for the app.<br />- For client credentials grants where the client is agent-linked, the `sub` claim is the agent's `agent_id`, or `external_agent_id` if one was set at creation. The `@clients` suffix is not appended in this case, nor for non-agent Machine-to-Machine apps on an API with agent subject claims enabled. See [Agents as Principal](/docs/ai-agents-mcp/agents-as-principal/agent-identity-in-tokens). | Yes | Yes | - User ID: `auth0\|6553da60a54af58e29493993`<br />- Client ID with suffix: `awZfdIir8YFdGZWkvCejDoUb7SjTDicx@clients`<br />- Agent ID: `agt_72jbvv7LfRKYp59gtRLtkn` |
| `aud` | The audience claim defines the intended recipient of the access token. | Yes | Yes | `"https://test-server/api"` or `[ "https://test-server/api", "https://test.local.dev.auth0.com/userinfo" ]` |
| `client_id` | Client ID of the application that requests the access token. | Yes | No | Client ID: `K1AUPhZq8mRi0Q0pjhkfu1D7y6KjDQja` |
| `azp` | Client ID of the application that requests the access token. | No | Yes | Client ID: `K1AUPhZq8mRi0Q0pjhkfu1D7y6KjDQja` |
| `exp` | The expiration time on or after which the access token must not be accepted. | Yes | Yes | Epoch timestamp: `1516238022` |
| `iat` | Timestamp at which the access token was issued. | Yes | Yes | Epoch timestamp: `1516239022` |
| `scope` | Scope of the issued access token. See [Scopes](/docs/get-started/apis/scopes). | Yes | Yes | `"openid profile offline_access"` |
| `jti` | Unique identifier for the access token. | Yes | No | Unique string identifier: `aBv9njtYfwL4xfPZyEwz9m` |
| `gty` | [Grant type](/docs/get-started/applications/application-grant-types) used to request the access token. Only present for `client-credentials`, `password`, and `refresh_token`. | No | Case-specific | Grant type: `password`, `client-credentials` |
| `permissions` | Permissions available depending on roles. Included when **Enable RBAC** and **Add permissions in the Access Token** are enabled. See [RBAC for APIs](/docs/get-started/apis/enable-role-based-access-control-for-apis). | Case-specific | Case-specific | `[ "create:bar", "create:foo", "read:bar", "read:foo" ]` |
| `org_id` | Organization ID. Added when user authenticated via an Organization. See [Tokens and Orgs](/docs/manage-users/organizations/using-tokens). | Case-specific | Case-specific | Organization ID: `org_9ybsU1dN2dKfDkBi` |
| `org_name` | Organization Name. Added when user authenticated via an Organization and **Organization Names in Authentication API** is enabled. See [Use Org Names](/docs/manage-users/organizations/configure-organizations/use-org-name-authentication-api). | Case-specific | Case-specific | Organization Name: `my_organization` |
| `authorization_details` | Authorization details used in Rich Authorization Requests (RAR). See [RAR](/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-rar). | Case-specific | Case-specific | `{ "type": "money_transfer", "instructedAmount": {"amount": 2500, "currency": "USD"}, "destinationAccount": "xxxx9876", "beneficiary": "Hanna Herwitz" }` |
| `cnf` | Confirmation claim for [mTLS Token Binding](/docs/get-started/applications/configure-sender-constraining/configure-resource-server-for-sender-constraining). | Case-specific | Case-specific | `{"x5t#S256":"A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0"}` |
| `sub_profile` | Entity type of the subject. Issued when `agent_subject_claims: 'auth0-v1'` is enabled on the resource server and an agent-linked client is involved. See [Agents as Principal](/docs/ai-agents-mcp/agents-as-principal/agent-identity-in-tokens). Values: `user`, `ai_agent`, `service`, `browser_app`, `native_app`. | Case-specific | Case-specific | `"ai_agent"` |
| `client_profile` | Entity type of the requesting client. Issued under the same conditions as `sub_profile`. Multiple space-separated values permitted. See [Agents as Principal](/docs/ai-agents-mcp/agents-as-principal/agent-identity-in-tokens). | Case-specific | Case-specific | `"service ai_agent"` |
| `act` | Actor claim per [RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693). Present when an agent-linked client is involved in a token exchange or standard login flow. Contains `sub`, `sub_profile`, `client_id`, `client_profile`, and optionally a nested `act` for multi-hop delegation chains. When an agent acts on behalf of a user, the agent is the outermost actor and any prior delegation chain is preserved as a nested `act`. See [Agents as Principal](/docs/ai-agents-mcp/agents-as-principal/agent-identity-in-tokens) and [The `act` claim](/docs/secure/call-apis-on-users-behalf/on-behalf-of-token-exchange#the-act-claim). | Case-specific | Case-specific | `{"sub": "agt_1a2b3c", "sub_profile": "ai_agent", "client_id": "agent-client-id"}` |
| Custom claims | Custom claims can be added via Actions. See [Create Custom Claims](/docs/secure/tokens/json-web-tokens/create-custom-claims). | Case-specific | Case-specific | `"favorite_color": "blue"` |