Microsoft Entra ID (Azure AD) JWT
Verify Microsoft Entra ID (Azure AD) JWTs. Issuer, JWKS, RS256 signing, v2.0 endpoint, tenant-specific iss, and the appid, oid, tid, ver claims explained with validation rules.
Microsoft Entra ID (formerly Azure Active Directory) issues JWTs for OAuth 2.0 and OpenID Connect. ID tokens and access tokens are both JWTs signed with RS256. The issuer is tenant-specific: https://login.microsoftonline.com/{tenant}/v2.0: the {tenant} is your directory tenant ID (a GUID) or a verified domain name.
Issuer details
| Property | Microsoft Entra ID (Azure AD) |
|---|---|
| Issuer (iss) | https://login.microsoftonline.com/{tenant}/v2.0 |
| JWKS URL | https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys |
| OIDC discovery | https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration |
| Signing algorithm | RS256 (default) |
Issuer-specific claims
Claims you will encounter in Microsoft Entra ID (Azure AD) JWTs and what they mean for this issuer:
Claim Meaning for this issuer isshttps://login.microsoftonline.com/{tenant}/v2.0: tenant-specific. Validate against your expected tenant, not a wildcard. oidObject ID: the user's stable identifier in Entra ID (a GUID). Use this as the primary key, not sub (which is per-application). tidTenant ID: the GUID of the Entra ID tenant the user authenticated in. Validate tid to restrict access to specific tenants (multi-tenant apps). subPer-application subject identifier. Unlike oid, sub differs across applications for the same user. Use oid for cross-application user identity. audYour application's client ID (a GUID). Validate this on every request. appidThe client ID of the application that requested the token (v1.0 tokens). In v2.0 tokens this is azp. verToken version: '1.0' or '2.0'. The claim set differs between versions (v1.0 has email, v2.0 may not). Configure your app to accept the version you issue. rolesApplication roles assigned to the user or service principal. Check these for role-based authorization.
Verifying tokens from this issuer
Fetch public keys from https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys. Hardcode algorithms: ['RS256']. Validate iss against your tenant-specific issuer URL (not a wildcard: multi-tenant apps must validate tid against an allowlist of accepted tenants). Validate aud against your client ID. Use the v2.0 endpoint for new apps; the v1.0 endpoint has a different claim set.
Frequently asked questions
-
What is the Microsoft Entra ID (Azure AD) JWT issuer URL?
The iss claim is tenant-specific: https://login.microsoftonline.com/{tenant}/v2.0 for the v2.0 endpoint, where {tenant} is your directory tenant ID (a GUID) or a verified domain name. Validate iss against your specific tenant: do not accept a wildcard. The JWKS endpoint is https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys and signs with RS256.
-
Should I use oid or sub in Azure AD JWTs?
Use oid (object ID) as the user's stable identifier. sub in Azure AD is per-application: the same user has a different sub in each application but the same oid across all applications in the tenant. Use oid as the primary key for cross-application user identity; use sub only within a single application's context.
-
How do I validate tenant in a multi-tenant Azure AD app?
Validate the tid (tenant ID) claim against an allowlist of tenant GUIDs you accept. In a multi-tenant app, any Entra ID tenant can authenticate, but you should only issue your app's authorization to tenants you have explicitly approved. Without tid validation, a user from any tenant (including personal Microsoft accounts) can authenticate to your app: which may be desired for consumer apps but is a security hole for B2B apps.
Related