Authentication and Authorization in Microsoft Entra ID – Understanding Authentication Flows, Tokens, and Protocols

Microsoft Entra ID (formerly Azure Active Directory) is the backbone of identity and access management (IAM) in the Microsoft ecosystem. It empowers apps and services to verify users securely and grant access based on their roles and permissions. Whether you’re building a cloud app, an enterprise SSO solution, or simply trying to understand how “Login with Microsoft Entra ID” works – you need to understand authentication flows, tokens, and protocols.

1. Authentication vs. Authorization

Before diving into Entra ID, let’s clarify the core concepts:

• Authentication (AuthN): Verifies who you are (e.g., signing in with a password, smartcard, or biometrics).
• Authorization (AuthZ): Determines what you can access (e.g., read a file, edit a database).

In Microsoft Entra ID, these processes are tightly integrated using modern protocols like OAuth 2.0 and OpenID Connect (OIDC).

Authentication is handled via protocols like OIDC and SAML, and authorization is performed using access tokens and role-based access control (RBAC).

2. AuthN and AuthZ Protocols: OAuth 2.0, OIDC, and SAML

✅ OAuth 2.0 (Authorization)

• OAuth 2.0 is an open-standard authorization framework that allows users to grant third-party applications access to their protected resources without revealing their login credentials.
• Purpose: Grants secure access to APIs without revealing credentials.
• Used for: Getting access tokens to access protected APIs.
• Example: A third-party calendar app requesting access to your Microsoft calendar.

✅ OpenID Connect (OIDC) (Authentication + Profile)

• Built on top of OAuth 2.0.
• Purpose: Modern authentication for web/ mobile apps.
• Key Components:
  • ID Token: Contains user identity claims (e.g., name, email).
  • Access Token: Grants access to APIs (e.g., Microsoft Graph).
• Uses JSON Web Tokens (JWTs).
• Used for: Logging in users and getting their profile info.
• Example: Signing into a web app with “Sign in with Microsoft”.

✅ SAML (Security Assertion Markup Language)

• Built on: XML-based assertions.
• Purpose: Legacy enterprise SSO for apps like Salesforce or SAP.
• Key Component: SAML Assertion (similar to tokens as proof of authentication).
• XML-based, legacy protocol for enterprise SSO.
• Exchanges SAML Assertions (similar to tokens).
• Used for: Federated login to classic web applications like SharePoint or SAP.
• More popular in enterprise setups with on-premises Active Directory.

3. SAML vs. OIDC – Differences

4. Authentication Flows in Microsoft Entra ID

Authentication flows are how your app gets tokens — different flows are chosen based on app type, user interactivity, and security needs. It defines how users/ apps obtain tokens from Entra ID. Each flow aligns with an OAuth 2.0 grant type and serves a specific use case:

✅ Authorization Code Flow (Recommended)

• Grant Type: authorization_code
• How It Works:
  1. User logs in via browser → Entra ID returns an authorization code. (NOT a token yet)
  2. App exchanges the code for ID token (user identity) and access token (API access).
• Use Case: Web/ mobile apps with a backend server.
• Security: Tokens are never exposed to the browser.
• Best for: Web apps or SPAs (with PKCE)

✅ Implicit Grant Flow (Legacy)

• Grant Type: implicit
• How It Works:
  • User logs in via browser
  • ID token or access token is returned directly in the URL fragment (no code exchange).
• Use Case: Legacy SPAs with no backend (e.g., AngularJS apps).
• Drawbacks: Deprecated due to token exposure in URLs.
• Replaced by Authorization Code Flow with PKCE.

✅ Hybrid Flow

• Grant Type: hybrid
• How It Works: Combines Authorization Code and Implicit flows:
  • Front-channel: Returns ID token immediately via front-channel (user’s browser).
  • Back-channel: Authorization code → exchanged for access token.
• Use Case: Apps needing user info upfront (e.g., role-based UI rendering).
• Best for: Apps that need immediate user info + backend token exchange.
• Combines the benefits of Authorization Code and Implicit Flow.

✅ Client Credentials Flow

• Grant Type: client_credentials
• How It Works:
  • App authenticates using its client ID and secret (no user involved).
  • Receives an access token to access APIs.
• Use Case: Background services (e.g., nightly data sync between APIs).
• Best for: Daemon apps or background services like microservices or automation scripts.

✅ Device Code Flow

• Grant Type: device_code
• How It Works:
  • The device shows a code and a login URL.
  • The user logs in on another device and enters the code.
  • Entra ID returns tokens after a successful login.
  • The app receives the tokens once the user is authenticated.
• Use Case: Smart TVs, IoT devices.
• Best for: Devices without browsers (e.g., Xbox, Smart TVs).

✅ Resource Owner Password Credentials (ROPC) Flow

• Grant Type: password
• How It Works:
  • The app collects the username and password directly.
  • Sends to Entra ID to get tokens.
• Use Case: Legacy migration (avoid for new apps).
• Best for: Legacy apps only.
• Risky: exposes credentials to the app.
• Use only if absolutely necessary and the app is trusted.

[Note: PKCE (pronounced “pixy”) stands for Proof Key for Code Exchange — it’s a security enhancement to the OAuth 2.0 Authorization Code flow, especially designed for public clients like mobile apps and single-page apps (SPAs) that cannot securely store client secrets.]

5. Understanding Grant Types

OAuth 2.0 defines grant types to specify how tokens are issued:

6. Understanding Token Types in Entra ID

🪪 ID Token

• Purpose: Authenticates the user and provides basic profile information.
• Protocol: OpenID Connect (extension of OAuth 2.0)
• Format: JSON Web Token (JWT).
• Use Case: Authentication (proof of who the user is)
• Contains: User info (name, email, user ID), issuer, audience, timestamps
• Used By: Apps to display user identity (e.g., show “Welcome, Alice”)
• Must be: Validated by the client app
• Ideal for web/mobile apps using Microsoft login or SSO.
• Used only for authentication (confirms user identity).
• Never used to access APIs.

🔐 Access Token

• Purpose: Grants access to protected resources (e.g., APIs).
• Protocol: OAuth 2.0 (and used in OIDC too)
• Format:
  • JWT (common in Entra ID): Contains scopes, audience (aud), and expiration.
  • Opaque String: Unreadable token validated via Entra ID’s introspection endpoint.
• Use Case: Authorization (used to access APIs like Microsoft Graph)
• Contains: Permissions (scopes), audience (API), expiration time
• Used By: APIs to verify what the app/user is allowed to do
• Apps must send access tokens in the Authorization: Bearer <token> header when calling APIs.
• Short-lived (default: 1 hour) for security reasons.

🔁 Refresh Token

• Purpose: The Refresh Token is used to obtain a new access token without requiring the user to re-authenticate, enabling seamless long-term access.
• Protocol: OAuth 2.0
• Use Case: To obtain new access tokens without re-authenticating
• Used By: Long-lived sessions like mobile apps or background apps
• Security Tip: Store securely and never expose it to the browser
• Often used in conjunction with access tokens to avoid logging in every hour.

🏢 SAML Assertion

• Purpose: Enables SSO for legacy enterprise applications.
• Protocol: SAML 2.0
• Use Case: Authentication and optional authorization in legacy or enterprise apps
• Format: XML (not JSON/JWT)
• Contains: User identity, issuer, validity period, and optional roles
• Exchanged between the Identity Provider (Entra ID) and the Service Provider (SP).
• Signed for integrity but less flexible than OIDC/OAuth.
• Common in enterprise environments using apps like SAP, Salesforce (legacy SSO).

ID Token vs Access Token

7. Some Real-World Use-Cases

✔️ Modern Web App + API Backend

• Flow: Authorization Code with PKCE.
• Tokens: ID Token (user identity), Access Token (API calls).

✔️ Mobile App

• Flow: Authorization Code with PKCE.
• Token Storage: Secure platform-specific storage (e.g., Android Keystore).

✔️ API-to-API Communication

• Flow: Client Credentials.
• Authentication: App registration with a certificate.

✔️ Legacy Enterprise App

• Protocol: SAML.
• Setup: Configure Entra ID as Identity Provider (IdP).

Final Thoughts

Understanding Entra ID’s authentication flows, tokens, and protocols empowers you to build secure, scalable applications. Whether you’re integrating a legacy SAML app or building a cutting-edge modern app or SPA, Entra ID provides the tools to balance usability and security.

References: Microsoft’s Entra ID Documentation.