> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/llms.txt
> Use this file to discover all available pages before exploring further.
> Learn about the access token profiles that Auth0 supports.
# Access Token Profiles
Access token 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:- `access_token`
- `access_token_authz`, or the `access_token` profile with the `permissions` claim included
|
| 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:- `rfc9068_profile`
- `rfc9068_profile_authz`, or the `rfc9068_profile` profile with the `permissions` claim included
|
While both access token profiles issue JWTs, 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 client ID 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
| 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:
- For grants where an end user is involved (e.g., Authorization Code Flow), the `sub` claim is the `user_id`.
- For Machine-to-Machine apps using Client Credentials (no end user), the `sub` claim is a unique identifier for the app. | Yes | Yes | - User ID: `auth0\|6553da60a54af58e29493993`
- Client ID with suffix: `awZfdIir8YFdGZWkvCejDoUb7SjTDicx@clients` |
| `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"}` |
| 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"` |