OAuth 2.0 / OIDC Flows: Complete Guide to Every Microsoft Entra ID Authentication Pattern

OAuth 2.0 and OIDC (OpenID Connect) are the two standard protocols that power authentication and authorization in Microsoft Entra ID. Every modern web app, mobile app, and backend service uses these flows to authenticate against Azure. This article walks through every flow used by Microsoft Entra ID, when to pick which one, and the implementation patterns you need to know.

OAuth 2.0 vs OIDC

Microsoft Entra ID supports both protocols, and access to Microsoft 365 / Azure services is implemented by combining OAuth 2.0 + OIDC. The standard pattern is to handle 'user login (OIDC)' and 'API access (OAuth 2.0)' together in a single end-to-end flow.

Authorization Code Flow + PKCE

The standard authentication flow for modern web and mobile apps.

Flow

1. The app generates a Code Verifier (random string) and sends a SHA-256-hashed Code Challenge to the Authorize endpoint
2. The user signs in to Microsoft Entra ID and consents
3. Entra ID redirects an Authorization Code back to the app
4. The app sends the Code + the original Code Verifier to the Token endpoint
5. Entra ID validates the Code and PKCE Challenge, then returns an ID Token + Access Token + Refresh Token

PKCE (Proof Key for Code Exchange) prevents code interception attacks against clients that cannot safely store a Client Secret, such as SPAs and mobile apps. For new web apps, Authorization Code + PKCE is recommended across every client type.

Implicit Flow (Deprecated)

The Implicit Flow is deprecated and should not be used for new implementations.

Problems

• Access Tokens linger in browser history
• Refresh Tokens cannot be issued
• Vulnerable to code interception attacks (CSRF Token Replay)

Alternative: SPAs should also use Authorization Code + PKCE, which is the current standard (natively supported by MSAL.js 2.x). Existing Implicit Flow apps should be migrated to Authorization Code + PKCE incrementally.

Client Credentials Flow

A flow that lets non-interactive backend services (daemons, cron jobs, worker processes) call Microsoft Graph or Azure APIs without user involvement.

How it works

1. The Service Principal sends its Client ID + Client Secret (or Certificate, or Workload Identity Federation) to the Token endpoint
2. Receives an Application Token (app-level permissions)
3. Calls the API with the Application Token

Typical use cases

• Scheduled backup apps
• Batch jobs that enumerate all tenant users
• DevOps pipelines manipulating Azure resources
• Webhook receivers

Eliminate secrets entirely with Workload Identity Federation — the modern best practice. See Managed Identity vs Service Principal for details.

On-Behalf-Of (OBO) Flow

A flow that lets an app where the user is already authenticated (the frontend) call another API (a backend or Microsoft Graph) while preserving the user's permissions.

Scenario

User → Frontend Web App (Entra ID auth) → Frontend calls Backend API → Backend calls Microsoft Graph on behalf of the user.

Flow

1. The Frontend obtains User Token A from the user via Authorization Code Flow
2. The Frontend calls the Backend API with Token A
3. The Backend sends Token A to the Token endpoint and requests 'Token B for Microsoft Graph carrying the same user permissions as Token A'
4. Entra ID issues Token B
5. The Backend calls Microsoft Graph with Token B

User permissions are inherited across multi-tier APIs, so the Backend never needs its own elevated Service Principal permissions.

Device Code Flow

A mechanism for authenticating users on devices that cannot present an interactive browser (IoT devices, CLI tools, smart TVs).

Flow

1. The device obtains a code (for example, ABCD-EFGH)
2. The device tells the user, 'Go to microsoft.com/devicelogin and enter ABCD-EFGH'
3. The user opens a browser on another PC or phone, signs in to Entra ID, enters the code, and consents
4. The device polls the Token endpoint
5. Once user authentication completes, the device receives the Token

Typical use cases

• az login (device-code option) in Azure CLI
• The Azure Account extension in Visual Studio Code
• Azure PowerShell
• First-time setup of embedded devices

Delegated vs Application Permissions

Design principle: user-facing apps should always use Delegated; backend services should combine Application + Workload Identity Federation.

Flow Selection Cheat Sheet

1. Web app (frontend / backend)? → Authorization Code + PKCE
2. SPA (React, Vue, Angular)? → Authorization Code + PKCE (Implicit is deprecated)
3. Mobile app (iOS / Android)? → Authorization Code + PKCE
4. Backend service (daemon, cron job)? → Client Credentials + Workload Identity Federation
5. Multi-tier API inheriting user permissions? → On-Behalf-Of
6. Headless CLI / IoT? → Device Code
7. Azure resource-to-resource auth? → Managed Identity (no need to think about flows)

Microsoft Authentication Library (MSAL)

MSAL is Microsoft's client library that abstracts OAuth 2.0 / OIDC flows. It supports multiple languages:

• MSAL.js: JavaScript / TypeScript (Web / Node.js)
• MSAL.NET: C# / .NET
• MSAL Python: Python
• MSAL Java: Java
• MSAL Go: Go
• MSAL iOS / Android: Mobile

Using MSAL directly is the standard for new implementations; ADAL (Active Directory Authentication Library) is legacy and deprecated. MSAL handles Token caching, automatic Refresh Token renewal, Conditional Access integration, and more for you.

Security Best Practices

1. Use Authorization Code + PKCE for every client type
2. Ban Implicit Flow in new implementations
3. Prefer Certificate / WIF over Client Secret
4. Grant Application Permissions sparingly and review Admin Consent carefully
5. Limit Token scopes (principle of least privilege)
6. Store Refresh Tokens securely (HTTPOnly Cookie, Secure Storage)
7. Use the MSAL library — avoid rolling your own
8. Apply Conditional Access to Service Principals via Conditional Access for Workload Identities (Preview)
9. Keep Token lifetimes short (use Continuous Access Evaluation for immediate revocation on anomalies)
10. Monitor abnormal Token issuance with Microsoft Sentinel

Related Certifications

• SC-300 (Identity and Access Administrator Associate): The headline cert for this area — covered in depth in Domain 3
• AZ-204 (Developer Associate): MSAL implementation in Domain 3
• AI-103 (2026-06 GA): Authentication patterns for Azure OpenAI / AI Search
• SC-100 (Cybersecurity Architect Expert): Zero-trust authentication architecture
• MS-102 (Microsoft 365 Administrator Expert): Domain 2

Frequently Asked Questions

The technical information in this article is based on the Microsoft Identity Platform Documentation and the MSAL Documentation. This article is not an official Microsoft Corporation product and has no affiliation or sponsorship arrangement with Microsoft. Microsoft, Azure, and Microsoft Entra are trademarks of the Microsoft group of companies. OAuth 2.0 is an IETF specification; OIDC is an OpenID Foundation specification. Information is based on official public materials as of May 24, 2026. Always check the official pages for the latest information.