Claims used in JSON web tokens are standardized in various normative documents. The dictionary below lists some of these registered claims; see IANA for a complete list.
Basic claims
Claims from the original JWT RFC document.
Earliest timestamp after which the token must be rejected as expired. Use of this claim is recommended in order to minimize impact of signing key being compromised.
Timestamp at which token was issued. Useful to determine the token age and for debugging purposes.
“Not before” timestamp restricting the minimum clock time required to accept the token (i.e., opposite of the exp claim).
Principal that has issued this token. Apps may use the claim to decide whether the issuer is trustworthy.
Describes entity that the claims apply to, generally by using its ID which is globally unique or unique to the issuing system. In the context of OAuth 2.0, the subject is the end user.
Identifies intended recipient(s) of the token. The token verifier must identify with a value in this claim; otherwise, token verification must fail.
Unique token identifier chosen using a collision-resistant algorithm (e.g., pseudo-randomly with sufficient entropy). Primarily useful to prevent replay attacks; with this claim, produced tokens are guaranteed to be unqiue.
OpenID Connect claims
Claims related to the idenitity of the token subject defined by the OpenID Connect framework.
Full name of the end user this token is issued to, potentially inlcuding titles and affixes if appropriate.
Dr. John William Doe, with the name components separated by a space charGiven name(s) of the user this token is issued to.
John WilliamLast name(s) of the user this token is issued to.
Ortega y GassetMiddle name(s) of the user this token is issued to.
IvanovichCasual name of the user this token is issued to. Semantically similar to the given_name claim.
MikeName identifying the user for the OAuth 2.0 client. This is usually a unique human-readable identifier of the user, but the verifier must not rely on this claim being unique.
j.doe or john.doe@example.comLink to the user’s profile page hosted by the issuer
https://example.com/u/john.doeLink to the user’s profile picture or photo hosted by the issuer
https://cdn.example.com/pics/127545457835.png. The URL must link to an image resource (e.g., a JPEG or PNG), rather than to an HTML page containing the image.Link to the user’s website, such as a blog
https://john-doe.example.com/Information on whether the issuer has verified the user’s email address provided in the email claim.
trueUser’s date of birth
User’s preferred time zone
User’s preferred locale
en-US or fr_CA. Both dash - and underscore _ separators between the language and country codes are allowed.User’s preferred phone number
+1 (425) 555-1212.Information on whether the issuer has verified the user’s phone number provided in the phone_number claim.
trueUser’s preferred postal address
formatted– Full mailing addressstreet_address– Part of the address related to the street, e.g. house number, street name, PO boxlocality– City / localityregion– State, province, region etc.postal_code– Zip code / postal codecountry– Country name
formatted and street_address fields can contain newlines, which can be represented as \r\n or \n chars.Timestamp when the user’s info was last updated
Authentication claims
Claims describing authentication undertaken by the subject in order to create an ID token within the OpenID Connect framework.
Timestamp when the user authenticated with the issuer
Unique value included into the token to prevent replay attacks. Similar to the jti claim, but can be specified by the authentication request when used within the OAuth 2.0 framework.
Reference to the method used to authenticate the user, or the class of this method. Classes may be represented by the applicable authentication level of assurance defined in the ISO/IEC 29115 standard. For example, level 2 (substantial) corresponds to multi-factor authentication, while level 0 is the least reliable (e.g., via a long-term authentication cookie).
2.References for the method(s) used to authenticate the user. As an example, this claim may signal that a password and an OTP scheme were used.
Party to which the token was issued. Fulfils almost the same role as the aud claim and is only really necessary if the audience claim has a single value, which is different from the authorized party.
Delegation claims
Claims related to authorization delegation as specified in the OAuth 2.0 token exchange framework.
Party to whom the subject has delegated authority to act on behalf of them. This claim can be used in scenarios such as tech support performing actions on behalf of a user.
sub claim, and may include other claims in order to uniquely identify the actor (e.g., the issuer – iss).Information about a party that is authorized to act on behalf of the subject. This can be used during OAuth 2.0 token exchange to determine whether the potential delegatee is valid, and to produce a token with the act claim as a result.
sub claim, and may include other claims in order to uniquely identify the actor (e.g., the issuer – iss).OAuth 2.0 claims
Claims applicable to tokens issued within miltiple OAuth 2.0 flows.
Collection of OAuth 2.0 scopes that allow restricting valid uses of the token. As an example, scopes can be used to restrict token to specific app(s) or service(s) within the verifier system.
email user_profile