JWT Claims Reference

Identifies the principal that issued the JWT.

Validation: Compare exactly with an issuer your application already trusts.

Identifies the subject represented by the JWT.

Validation: Interpret only inside the issuer namespace and after issuer validation.

Identifies intended recipients of the JWT.

Validation: Require the resource server's expected audience to be present.

Time after which the JWT must not be accepted.

Validation: Reject after exp, allowing only a small configured clock tolerance.

Time before which the JWT must not be accepted.

Validation: Reject before nbf, subject to configured clock tolerance.

Time at which the JWT was issued.

Validation: Use for age/lifetime policy; reject implausible future values.

Unique identifier for the JWT.

Validation: Use with application state when replay detection or revocation requires uniqueness.

Identifies the party to which the ID Token was issued.

Validation: Check when the ID Token has multiple audiences or your client policy requires it.

Binds an ID Token to the browser/client authentication request.

Validation: Compare with the nonce stored for the authorization request to prevent replay.

Time when end-user authentication occurred.

Validation: Use when max_age or reauthentication policy depends on authentication age.

Identifier for the authentication context class achieved.

Validation: Interpret only against assurance levels your application explicitly recognizes.

Lists authentication methods used, such as password or MFA-related methods.

Validation: Do not infer assurance from unknown values; use issuer-defined semantics.

Hash-derived value that can bind an access token to an ID Token.

Validation: Validate when required by the OIDC flow and response type.

Hash-derived value that can bind an authorization code to an ID Token.

Validation: Validate when the OIDC response type requires it.

Hash-derived value used by profiles to bind state to a signed response.

Validation: Apply only when the active OIDC/FAPI profile requires it.

Identifier for an OpenID Provider session.

Validation: Treat as issuer-scoped session metadata, not a globally unique user identifier.

End-user's full display name.

Validation: Profile data; do not use as a stable authorization identifier.

End-user's given or first name.

Validation: Profile data; presentation and localization rules may apply.

End-user's surname or last name.

Validation: Profile data; do not assume uniqueness.

End-user's middle name.

Validation: Optional profile data.

Casual name by which the end-user may be addressed.

Validation: Presentation data only.

Shorthand name the end-user prefers.

Validation: Do not assume global uniqueness or immutability.

URL of the end-user's profile page.

Validation: Treat as profile data and validate URL handling before rendering links.

URL of the end-user's profile picture.

Validation: Treat as untrusted remote content when rendering.

URL of the end-user's web page or blog.

Validation: Treat as untrusted profile data.

End-user's preferred email address.

Validation: Do not treat as verified unless email_verified is true and the issuer is trusted.

Indicates whether the issuer has verified control of the email address.

Validation: Meaning is issuer-specific; validate issuer trust before relying on it.

End-user's gender value as supplied by the issuer.

Validation: Optional profile data; minimize collection where unnecessary.

End-user's birthday in an ISO 8601 compatible form.

Validation: Sensitive profile data; avoid using it as an authentication factor.

End-user's time zone identifier.

Validation: Presentation/profile preference only.

End-user's locale preference.

Validation: Use for presentation; do not make trust decisions from locale.

End-user's preferred telephone number.

Validation: Do not treat as verified unless phone_number_verified is true and issuer trust is established.

Indicates whether the issuer verified control of the phone number.

Validation: Meaning depends on issuer policy and verification method.

Structured postal address object.

Validation: Sensitive profile data; validate nested fields before display.

Time when the end-user information was last updated.

Validation: Use only as profile freshness metadata.

Identifies the OAuth client associated with the access token.

Validation: Compare only when resource-server policy depends on a specific client.

Delegated permissions associated with the access token.

Validation: Authorize only scopes your resource understands and that apply to the token audience.

Role values used for authorization outside simple delegated-scope models.

Validation: Treat semantics as issuer/resource-specific; deny unknown roles by default.

Group membership values carried for authorization decisions.

Validation: Do not assume naming or nesting semantics across issuers.

Entitlement values representing rights or permissions.

Validation: Require an application-defined mapping from entitlement to allowed action.

Declares proof-of-possession key confirmation information.

Validation: Validate the confirmation method required by the active token/profile instead of treating cnf as informational.

Identifies the acting party in delegated or impersonation scenarios.

Validation: Distinguish actor from subject when applying authorization or audit policy.

Identifies parties authorized to act for the subject.

Validation: Use only in token-exchange designs that explicitly define delegation policy.

Common application-specific list of allowed actions.

Validation: Private claim: define exact issuer, audience and permission semantics in your application.

Singular or multi-valued application role convention.

Validation: Do not assume equivalence with roles; map it explicitly per issuer.

Common convention for tenant or organization routing.

Validation: Never use a tenant value to establish issuer trust; validate it against authenticated context.

Common organization identifier used by SaaS authorization models.

Validation: Treat as issuer-specific and enforce resource membership separately.

Common vendor convention distinguishing token purposes such as access or identity.

Validation: Use only when documented by the issuer; prefer standardized typ/profile rules where available.