Microsoft identity platform ID tokens

id_tokens are sent to the client application as part of an OpenID Connect (OIDC) flow. They can be sent along side or instead of an access token, and are used by the client to authenticate the user.

Using the id_token

ID Tokens should be used to validate that a user is who they claim to be and get additional useful information about them - it shouldn't be used for authorization in place of an access token. The claims it provides can be used for UX inside your application, as keys in a database, and providing access to the client application. When creating keys for a database, idp should not be used because it messes up guest scenarios. Keying should be done on sub alone (which is always unique), with tid used for routing if need be. If you need to share data across services, oid+sub+tid will work since multiple services all get the same oid.

Claims in an id_token

id_tokens for a Microsoft identity are JWTs (JSON Web Tokens), meaning they consist of a header, payload, and signature portion. You can use the header and signature to verify the authenticity of the token, while the payload contains the information about the user requested by your client. Except where noted, all JWT claims listed here appear in both v1.0 and v2.0 tokens.



View this v1.0 sample token in



View this v2.0 sample token in

Header claims

Claim Format Description
typ String - always "JWT" Indicates that the token is a JWT token.
alg String Indicates the algorithm that was used to sign the token. Example: "RS256"
kid String Thumbprint for the public key used to sign this token. Emitted in both v1.0 and v2.0 id_tokens.
x5t String The same (in use and value) as kid. However, this is a legacy claim emitted only in v1.0 id_tokens for compatibility purposes.

Payload claims

This list shows the JWT claims that are in most id_tokens by default (except where noted). However, your app can use optional claims to request additional JWT claims in the id_token. These can range from the groups claim to information about the user's name.

Claim Format Description
aud String, an App ID URI Identifies the intended recipient of the token. In id_tokens, the audience is your app's Application ID, assigned to your app in the Azure portal. Your app should validate this value, and reject the token if the value does not match.
iss String, an STS URI Identifies the security token service (STS) that constructs and returns the token, and the Azure AD tenant in which the user was authenticated. If the token was issued by the v2.0 endpoint, the URI will end in /v2.0. The GUID that indicates that the user is a consumer user from a Microsoft account is 9188040d-6c67-4c5b-b112-36a304b66dad. Your app should use the GUID portion of the claim to restrict the set of tenants that can sign in to the app, if applicable.
iat int, a UNIX timestamp "Issued At" indicates when the authentication for this token occurred.
idp String, usually an STS URI Records the identity provider that authenticated the subject of the token. This value is identical to the value of the Issuer claim unless the user account not in the same tenant as the issuer - guests, for instance. If the claim isn't present, it means that the value of iss can be used instead. For personal accounts being used in an organizational context (for instance, a personal account invited to an Azure AD tenant), the idp claim may be '' or an STS URI containing the Microsoft account tenant 9188040d-6c67-4c5b-b112-36a304b66dad.
nbf int, a UNIX timestamp The "nbf" (not before) claim identifies the time before which the JWT MUST NOT be accepted for processing.
exp int, a UNIX timestamp The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. It's important to note that a resource may reject the token before this time as well - if, for example, a change in authentication is required or a token revocation has been detected.
c_hash String The code hash is included in ID tokens only when the ID token is issued with an OAuth 2.0 authorization code. It can be used to validate the authenticity of an authorization code. For details about performing this validation, see the OpenID Connect specification.
at_hash String The access token hash is included in ID tokens only when the ID token is issued with an OAuth 2.0 access token. It can be used to validate the authenticity of an access token. For details about performing this validation, see the OpenID Connect specification.
aio Opaque String An internal claim used by Azure AD to record data for token reuse. Should be ignored.
preferred_username String The primary username that represents the user. It could be an email address, phone number, or a generic username without a specified format. Its value is mutable and might change over time. Since it is mutable, this value must not be used to make authorization decisions. The profile scope is required to receive this claim.
email String The email claim is present by default for guest accounts that have an email address. Your app can request the email claim for managed users (those from the same tenant as the resource) using the email optional claim. On the v2.0 endpoint, your app can also request the email OpenID Connect scope - you don't need to request both the optional claim and the scope to get the claim. The email claim only supports addressable mail from the user's profile information.
name String The name claim provides a human-readable value that identifies the subject of the token. The value isn't guaranteed to be unique, it is mutable, and it's designed to be used only for display purposes. The profile scope is required to receive this claim.
nonce String The nonce matches the parameter included in the original /authorize request to the IDP. If it does not match, your application should reject the token.
oid String, a GUID The immutable identifier for an object in the Microsoft identity system, in this case, a user account. This ID uniquely identifies the user across applications - two different applications signing in the same user will receive the same value in the oid claim. The Microsoft Graph will return this ID as the id property for a given user account. Because the oid allows multiple apps to correlate users, the profile scope is required to receive this claim. Note that if a single user exists in multiple tenants, the user will contain a different object ID in each tenant - they're considered different accounts, even though the user logs into each account with the same credentials. The oid claim is a GUID and cannot be reused.
roles Array of strings The set of roles that were assigned to the user who is logging in.
rh Opaque String An internal claim used by Azure to revalidate tokens. Should be ignored.
sub String, a GUID The principal about which the token asserts information, such as the user of an app. This value is immutable and cannot be reassigned or reused. The subject is a pairwise identifier - it is unique to a particular application ID. If a single user signs into two different apps using two different client IDs, those apps will receive two different values for the subject claim. This may or may not be wanted depending on your architecture and privacy requirements.
tid String, a GUID A GUID that represents the Azure AD tenant that the user is from. For work and school accounts, the GUID is the immutable tenant ID of the organization that the user belongs to. For personal accounts, the value is 9188040d-6c67-4c5b-b112-36a304b66dad. The profile scope is required to receive this claim.
unique_name String Provides a human readable value that identifies the subject of the token. This value is unique at any given point in time, but as emails and other identifiers can be reused, this value can reappear on other accounts, and should therefore be used only for display purposes. Only issued in v1.0 id_tokens.
uti Opaque String An internal claim used by Azure to revalidate tokens. Should be ignored.
ver String, either 1.0 or 2.0 Indicates the version of the id_token.


The v1 and v2 id_token have differences in the amount of information they will carry as seen from the examples above. The version essentially specifies the Azure AD platform endpoint from where it was issued. Azure AD Oauth implementation have evolved through the years. Currently we have two different oAuth endpoints for AzureAD applications. You can use any of the new endpoints which are categorized as v2 or the old one which is said to be v1. The Oauth endpoints for both of them are different. The V2 endpoint is the newer one where we are trying to migrate all the features of v1 endpoint and recommend new developers to use the v2 endpoint.

  • V1: Azure Active Directory Endpoints:
  • V2: Microsoft Identity Platform Endpoints:

Validating an id_token

Validating an id_token is similar to the first step of validating an access token - your client should validate that the correct issuer has sent back the token and that it hasn't been tampered with. Because id_tokens are always a JWT token, many libraries exist to validate these tokens - we recommend you use one of these rather than doing it yourself.

To manually validate the token, see the steps details in validating an access token. After validating the signature on the token, the following JWT claims should be validated in the id_token (these may also be done by your token validation library):

  • Timestamps: the iat, nbf, and exp timestamps should all fall before or after the current time, as appropriate.
  • Audience: the aud claim should match the app ID for your application.
  • Nonce: the nonce claim in the payload must match the nonce parameter passed into the /authorize endpoint during the initial request.

Next steps