Understanding the OAuth 2.0 and OpenID Connect duo
Microsoft Entra ID, formerly Azure AD, relies on two open standards that must never be confused. OAuth 2.0 is an authorization framework: it defines how an application obtains the right to access a resource on behalf of a user. OpenID Connect (OIDC) is an authentication overlay built on top of OAuth 2.0: it answers the question "who is this user?".
This distinction is not theoretical. It determines the type of token your application must request, the endpoint to call, and how to validate the response. An application that confuses the two often ends up using an ID Token to call an API, which systematically fails on the validation side.
Microsoft Identity Platform v2.0
This model corresponds to the v2.0 endpoint of the Microsoft identity platform, the one used by default for any new application registration in the Microsoft Entra admin center portal. The older Azure AD v1.0 endpoint remains supported for backward compatibility but is no longer recommended for new developments.
The actors involved in an authentication scenario
Four actors systematically intervene in an Entra ID flow:
- The user: authenticates with their credentials, potentially strengthened by multi-factor authentication (MFA) or a passwordless method like Windows Hello for Business.
- The client application: web app, mobile, Single Page Application (SPA), desktop client or daemon service without user interaction.
- The APIs: Microsoft Graph, a custom business API exposed in Entra ID, or a third-party API.
- Microsoft Entra ID: acts as an Identity Provider and issues all tokens.
OAuth 2.0 delivers Access Tokens consumed by APIs. OpenID Connect delivers ID Tokens that identify the user to the client application. This complementarity enables both secure access to resources and a consistent Single Sign-On (SSO) experience across Microsoft applications and third-party applications registered in the tenant.
The Authorization Code flow, the reference for modern applications
The Authorization Code Flow remains the recommended scenario for the majority of web, mobile and desktop applications. It prevents a token from traveling in clear text through the browser, unlike implicit flows which are now discouraged.
Redirect to the /authorize endpoint
The user attempts to access the application. The application redirects the browser to Microsoft Entra ID's /authorize endpoint with the parameters client_id, scope, redirect_uri and response_type=code.
User authentication
The user authenticates using the method configured in the conditional access policy: password, MFA or Windows Hello. Entra ID evaluates applicable Conditional Access policies in the process.
Return of the authorization code
Once authentication is validated, Entra ID redirects the user to the redirect_uri declared in the application registration with a short-lived authorization code.
Exchange code for tokens
The application calls the /token endpoint in back-channel to exchange this code for tokens. Three tokens can be issued at this stage: the ID Token, the Access Token and the Refresh Token.
1POST /oauth2/v2.0/token HTTP/1.12Host: login.microsoftonline.com3Content-Type: application/x-www-form-urlencoded4 5grant_type=authorization_code6&client_id={client_id}7&code={code_recu}8&redirect_uri={redirect_uri}9&client_secret={client_secret}Call the API with the Access Token
The application transmits the Access Token in the Authorization: Bearer header of each API call. The API validates the token signature, its expiration and its audience (claim aud) before returning the data.
PKCE mandatory for public clients
For SPAs and mobile applications, Microsoft requires the PKCE (Proof Key for Code Exchange) extension. Without a reliable client secret, PKCE prevents interception of the authorization code by generating a code_verifier / code_challenge pair unique to each login attempt.
The endpoints exposed by Microsoft Entra ID
Any OAuth 2.0 / OIDC integration relies on a set of standardized endpoints, all accessible under login.microsoftonline.com/{tenant}:
| Endpoint | Role | Typical usage |
|---|---|---|
| /authorize | Authenticates the user and grants authorization | Entry point of the Authorization Code flow |
| /token | Issues tokens (ID, Access, Refresh) | Code exchange or session renewal |
| /.well-known/openid-configuration | Discovery Endpoint: exposes OIDC metadata | Automatic configuration of MSAL libraries |
| JWKS Endpoint | Publishes public signature keys | Cryptographic validation of tokens on the API side |
| UserInfo (Microsoft Graph) | Returns the profile of the connected user | Additional information after authentication |
Choosing the right flow according to application type
The choice of OAuth 2.0 flow depends directly on the nature of the client application. A wrong choice unnecessarily exposes secrets or complicates maintenance.
| Flow | Use case | User interaction |
|---|---|---|
| Authorization Code Flow | Confidential web, mobile and desktop applications | Yes |
| Authorization Code + PKCE | SPAs and public mobile applications | Yes |
| Client Credentials Flow | Service-to-service communication, daemons | No |
| Device Code Flow | CLI, IoT devices without browser | Yes (on another device) |
| On-Behalf-Of (OBO) | API calling another API on behalf of the user | No (transitive delegation) |
| Refresh Token Flow | Silent renewal of an existing session | No |
The Client Credentials Flow is reserved for scenarios without a user, often with a service principal or managed identity. The On-Behalf-Of flow intervenes in chain API architectures, typically a business API that relays a call to Microsoft Graph with the context of the original user.
The three types of tokens and their exact role
Each token issued by Microsoft Entra ID has a precise purpose, and confusing them is a frequent source of 401 errors on the API side:
- ID Token: JWT (JSON Web Token) token in OIDC format, contains identity claims (
sub,name,oid,tid). It is exclusively for the client application to establish the session and SSO, never to call an API. - Access Token: carries the granted scopes and permissions (
https://graph.microsoft.com/User.Readfor example). It is the only token to transmit to APIs in theAuthorizationheader. - Refresh Token: allows obtaining a new Access Token without going through interactive authentication again. Its lifetime and revocation conditions are controlled by session policies configurable in Entra ID.
Validation on the API side
An API must never merely decode a token: it must verify the signature via the JWKS Endpoint keys, check the expiration (exp), the audience (aud) and the issuer (iss). The Microsoft.Identity.Web libraries for .NET or MSAL natively cover these verifications.
Key points to remember
- OAuth 2.0 manages authorization and produces Access Tokens for APIs; OpenID Connect manages authentication and produces ID Tokens for the application.
- The Authorization Code Flow, supplemented by PKCE for public clients, remains the reference scenario recommended by Microsoft.
- The choice of flow (Client Credentials, Device Code, On-Behalf-Of, Refresh Token) depends strictly on the type of application and the presence or absence of an interactive user.
- The
/authorize,/tokenendpoints, the Discovery Endpoint and the JWKS Endpoint form the technical foundation of any integration. - Never use an ID Token to call an API: only the Access Token carries the necessary scopes.
To deepen the concrete implementation, the official documentation details each flow with examples of HTTP requests: Microsoft identity platform and OAuth 2.0 authorization code flow and Microsoft identity platform and OpenID Connect protocol.
