JSON Web Token Claims

JSON web tokens (JWTs) claims are pieces of information asserted about a subject. For example, an ID token (which is always a JWT) can contain a claim called name that asserts that the name of the user authenticating is "John Doe". In a JWT, a claim appears as a name/value pair where the name is always a string and the value can be any JSON value. Generally, when we talk about a claim in the context of a JWT, we are referring to the name (or key). For example, the following JSON object contains three claims (sub, name, admin):

{
      "sub": "1234567890",
      "name": "John Doe",
      "admin": true
    }

Was this helpful?

/

There are two types of JWT claims:

  • Registered: standard claims registered with the Internet Assigned Numbers Authority (IANA) and defined by the JWT specification to ensure interoperability with third-party, or external, applications. OIDC standard claims are reserved claims.

  • Custom:  consists of non-registered public or private claims. Public claims are collision-resistant while private claims are subject to possible collisions.

Registered claims

The JWT specification defines seven reserved claims that are not required, but are recommended to allow interoperability with third-party applications. These are:

  • iss (issuer): Issuer of the JWT

  • sub (subject): Subject of the JWT (the user)

  • aud (audience): Recipient for which the JWT is intended

  • exp (expiration time): Time after which the JWT expires

  • nbf (not before time): Time before which the JWT must not be accepted for processing

  • iat (issued at time): Time at which the JWT was issued; can be used to determine age of the JWT

  • jti (JWT ID): Unique identifier; can be used to prevent the JWT from being replayed (allows a token to be used only once)

You can see a full list of registered claims at the IANA JSON Web Token Claims Registry.

Custom claims

You can define your own custom claims which you control and you can add them to a token using Actions. Here are some examples:

  • Add a user's email address to an access token and use that to uniquely identify the user.

  • Add custom information stored in an Auth0 user profile to an ID token.

As long as the Action is in place, the custom claims it adds will appear in new tokens issued when using a refresh token.

For an example showing how to add custom claims to a token, see Sample Use Cases: Scopes and Claims.

Public claims

You can create custom claims for public consumption, which might contain generic information like name and email. If you create public claims, you must either register them or use collision-resistant names through namespacing and take reasonable precautions to make sure you are in control of the namespace you use.

In the IANA JSON Web Token Claims Registry, you can see some examples of public claims registered by OpenID Connect (OIDC):

  • auth_time

  • acr

  • nonce

Private claims

You can create private custom claims to share information specific to your application. For example, while a public claim might contain generic information like name and email, private claims would be more specific, such as employee ID and department name.

Auth0 restrictions

Auth0 enforces the general restrictions on custom claims: 

  • custom claims payload is set to a maximum of 100KB

  • a subset of OIDC and other registered standard claims or claims used internally by Auth0 cannot be customized or modified

  • access tokens with an Auth0 API audience, excluding the /userinfo endpoint, cannot have private, non-namespaced custom claims 

  • only specified OIDC user profile claims can be added to access tokens

To learn more about custom claims, read Create Custom Claims.

Learn more