Common claims found in Azure AD OAuth tokens include the following:
* aud (Audience): This identifies the intended recipient of the token, which, for Azure AD B2C, is the application ID. Applications should validate this value to ensure it matches their ID and reject the token if it doesn't[3]. The audience is synonymous with resource[3].
* iss (Issuer): This claim identifies the security token service (STS) that constructed and returned the token, and also identifies the directory where the user was authenticated. Applications should validate this claim to ensure the token came from the appropriate endpoint[3].
* iat (Issued at): This represents the time at which the token was issued, in epoch time[3].
* exp (Expiration time): This indicates the time at which the token becomes invalid, represented in epoch time. Applications should use this claim to verify the validity of the token lifetime[3].
* nbf (Not before): This claim specifies the time at which the token becomes valid, in epoch time. It is usually the same as the time the token was issued, and your application should use this claim to verify the validity of the token lifetime[3].
* ver (Version): This indicates the version of the ID token, as defined by Azure AD B2C[3].
* c_hash (Code hash): Included in an ID token only when the token is issued together with an OAuth 2.0 authorization code. It can be used to validate the authenticity of an authorization code[3].
* at_hash (Access token hash): Included in an ID token only when the token is issued together with an OAuth 2.0 access token, and used to validate the authenticity of an access token[3].
* nonce: A strategy used to mitigate token replay attacks. Your application can specify a nonce in an authorization request by using the `nonce` query parameter. The value you provide in the request is emitted unmodified in the `nonce` claim of an ID token only[3].
* sub (Subject): This claim represents the principal about which the token asserts information, such as the user of an application. The value is immutable and can't be reassigned or reused. It can be used to perform authorization checks safely. By default, the subject claim is populated with the object ID of the user in the directory[3].
* acr (Authentication context class reference): Used only with older policies[3].
* tfp (Trust framework policy): The name of the policy that was used to acquire the ID token[3].
* auth\_time: The time at which a user last entered credentials, represented in epoch time. There's no discrimination between that authentication being a fresh sign-in, a single sign-on (SSO) session, or another sign-in type[3].
* scp (Scope): This refers to the permissions granted to the resource for an access token. Multiple granted permissions are separated by a space[3].
* azp (Authorized Party): The application ID of the client application that initiated the request[3].
* oid: This claim contains the unique identifier of an object in Azure AD, is immutable, and cannot be reassigned or reused. It can be used to identify an object in queries to Azure AD[1].
Citations:
[1] https://stackoverflow.com/questions/40972416/what-jwt-claims-from-azure-ad-tokens-can-be-safely-used-for-user-mappings
[2] https://stackoverflow.com/questions/70867353/azure-access-token-contains-info-that-i-thought-would-be-in-the-id-token-and-vi
[3] https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/active-directory-b2c/tokens-overview.md
[4] https://www.descope.com/blog/post/noauth
[5] https://learn.microsoft.com/en-us/entra/identity-platform/access-token-claims-reference
[6] https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/
[7] https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference
[8] https://www.descope.com/blog/post/access-token-vs-refresh-token