OAuth 2.0 and OpenID Connect in Entra

OAuth 2.0 (RFC 6749) is an authorization framework that enables a third-party application to obtain limited access to an HTTP service on behalf of a resource owner. It does this by issuing an access token to the client application, which the client presents to the resource server to access protected resources. OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0 (specifically OIDC Core 1.0). It adds an ID token—a JSON Web Token (JWT) that contains claims about the authenticated user's identity.

Before OAuth 2.0, applications often required users to share their passwords directly with third-party apps (the "password anti-pattern"). This was insecure because the app gained full access to the user's account. OAuth 2.0 solves this by allowing the user to grant a scoped, revocable token without sharing credentials. OIDC solves the problem of verifying identity: OAuth 2.0 alone does not provide a standardized way to know who the user is—only that they have authorized access.

The OAuth 2.0 flow involves four main roles: - Resource Owner: The user who owns the data. - Client: The application requesting access. - Authorization Server (AS): The server that issues tokens after authenticating the resource owner and obtaining authorization (in Entra ID, this is the Microsoft identity platform endpoint). - Resource Server (RS): The server hosting the protected resources (e.g., Microsoft Graph API).

The standard flow (Authorization Code Grant) proceeds as follows: 1. The client redirects the user to the authorization server with a request that includes: client_id, redirect_uri, response_type=code, and scope. 2. The authorization server authenticates the user (e.g., via username/password, MFA) and asks for consent to the requested scopes. 3. Upon consent, the authorization server redirects the user back to the client with an authorization code in the query string. 4. The client sends a POST request to the token endpoint with the authorization code, client credentials, and redirect_uri. The server returns an access token (and optionally a refresh token). 5. The client uses the access token to call the resource server.

OpenID Connect extends this by requesting the openid scope. When the client includes scope=openid, the authorization server returns an ID token alongside the access token. The ID token is a JWT that contains claims such as sub (subject identifier), iss (issuer), aud (audience), exp (expiration), and iat (issued at). The client must validate the ID token by checking the signature (using the public keys from the JWKS endpoint) and the claims.

In Azure, you can configure OAuth 2.0 settings in the App Registration blade. Key settings include: - Redirect URIs: Must be exact match, including protocol and trailing slash. - Implicit grant: Legacy; should be avoided. Allows returning tokens directly in the URL fragment for SPAs. - Certificates & secrets: Client secrets (string) or certificates (X.509) for client authentication. - API permissions: Define required scopes and grant admin consent.

To verify token content, use a JWT decoder (e.g., jwt.ms). For example, an access token decoded looks like:

{
  "aud": "https://graph.microsoft.com",
  "iss": "https://sts.windows.net/{tenant-id}/",
  "iat": 1680000000,
  "nbf": 1680000000,
  "exp": 1680003600,
  "appid": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "scp": "User.Read Mail.Read",
  "sub": "...",
  "tid": "...",
  "ver": "2.0"
}

To test the flow, you can use the Microsoft Authentication Library (MSAL) or tools like Postman with the OAuth 2.0 authorization code grant.

OAuth 2.0 and OIDC are the foundation for almost all modern authentication in Entra ID. They integrate with: - Conditional Access: Policies can require specific authentication strengths (e.g., MFA) or block certain locations. The authorization server enforces these policies during token issuance. - Microsoft Graph: The resource server that validates access tokens for Microsoft 365 data. - Azure AD B2C: A separate service that uses the same protocols but allows custom user journeys and social identity providers. - Federation (e.g., AD FS): When federated, the Entra ID authorization server redirects to the on-premises STS for authentication, but the token issuance still follows OAuth 2.0/OIDC. - Managed Identities: Use a variant of the client credentials grant; Azure automatically manages the token acquisition for Azure resources like VMs and Functions.

Understanding these flows and their use cases is critical for SC-900 scenario questions.

Enterprise Scenario 1: Single-Page Application (SPA) Accessing Microsoft Graph

A company builds a React SPA that reads user calendar events from Microsoft Graph. The app uses MSAL.js to implement the authorization code grant with PKCE. The redirect URI is registered as https://app.contoso.com/callback. The app requests scopes openid profile User.Read Calendars.Read. When a user signs in, they are redirected to Entra ID, authenticate with MFA (enforced by Conditional Access), and consent. The app receives an authorization code, exchanges it for tokens, and uses the access token to call Graph. The access token expires after 1 hour; the app uses the refresh token to silently acquire a new token. Common issues: incorrect redirect URI (trailing slash mismatch), expired client secret, or missing admin consent for delegated permissions.

Enterprise Scenario 2: Daemon Service Calling Microsoft Graph

A background service needs to read all users' profiles in the tenant. No user interaction is possible. The app uses the client credentials grant. The app registers a client secret and requests application permissions (e.g., User.Read.All). An admin must grant admin consent for this permission because it allows access to all users. The app authenticates directly to the token endpoint with its client credentials and receives an access token. The token has no user context; the sub claim is the app's service principal. The service then calls Graph with this token. Performance consideration: token acquisition is fast (milliseconds), but the token must be cached to avoid hitting rate limits. Misconfiguration: if the client secret is exposed, an attacker can obtain tokens with high privileges. Best practice: use certificate-based authentication and rotate secrets regularly.

Enterprise Scenario 3: Multi-Tier API Using On-Behalf-Of Flow

A web API (middle-tier) receives a request from a client app and needs to call another downstream API (e.g., Microsoft Graph) on behalf of the original user. The web API receives an access token scoped for its own API. It then uses the On-Behalf-Of flow: it sends a POST to the token endpoint with grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer, assertion (the incoming token), scope (e.g., User.Read), and client_id/client_secret. Entra ID validates the incoming token and issues a new access token for the downstream API. The web API must be configured as an 'exposed API' with appropriate scopes and have permissions to the downstream API. Common failure: the incoming token's aud does not match the middle-tier API's client ID, or the middle-tier API lacks delegated permissions.