Confused by Sign-In Flows? Compare Microsoft Entra Authentication Flows

Microsoft Entra ID supports many ways to sign in users, apps, workloads, and devices.

Use this trip as a map before choosing a flow.

Understand the Scope

Authentication flows answer different questions:

Who is signing in?
Is a user present?
Is this a browser, mobile app, CLI, backend service, or workload?
Does the app need only sign-in, or also API access?
Can the workload use managed identity or federation instead of a secret?

Do not choose a flow only because it works in a demo. Choose the flow that matches the app type and security boundary.

Quick Decision Table

Scenario	Use this flow	Main idea
Server-side web app signs in a user	Authorization code flow	Browser receives a code, backend exchanges it for tokens
Single-page app signs in a user	Authorization code flow with PKCE	Browser receives a code, app exchanges it using PKCE
CLI or device without easy browser input	Device code flow	User signs in on another device using a code
Backend service calls an API as itself	Client credentials flow	App uses its own identity, not a user
Azure workload calls Azure resource	Managed identity	Azure provides the workload identity
GitHub or Azure DevOps pipeline calls Azure	Workload identity federation	CI/CD exchanges an external token for an Entra token
API calls another API for a signed-in user	On-behalf-of flow	API exchanges the incoming user token for a downstream API token
SaaS app needs enterprise SSO	SAML or OIDC	Entra proves the user’s identity to the SaaS app
Legacy browser app returns tokens directly	Implicit or hybrid flow	Token returns through browser; avoid for new apps

User Sign-In Flows

Authorization Code Flow

Use this for server-side web apps.

The browser signs the user in, but the backend app receives the authorization code and exchanges it for tokens.

user opens app
> app redirects browser to Entra
> user signs in
> Entra redirects browser back with code
> backend exchanges code for tokens
> app creates session

This is the normal choice for traditional web apps because tokens can stay on the server.

Authorization Code Flow with PKCE

Use this for single-page apps, mobile apps, and public clients.

PKCE protects the code exchange when the app cannot safely hold a client secret.

app creates code verifier and challenge
> user signs in
> Entra returns code
> app exchanges code with code verifier

This is the modern replacement for implicit flow in browser-based apps.

Device Code Flow

Use this for command-line tools, scripts, or devices where browser sign-in is awkward.

CLI shows a code
> user opens browser on another device
> user enters code and signs in
> CLI receives tokens

Device code flow is user-delegated. The CLI acts with the signed-in user’s permissions.

Implicit and Hybrid Flow

Use this only when maintaining legacy apps.

Implicit flow returns tokens directly through the browser.

response_type=id_token

Hybrid flow mixes code flow with direct token return.

response_type=code id_token

For new apps, use authorization code flow with PKCE instead.

App and Workload Flows

Client Credentials Flow

Use this when a backend service calls an API as itself.

There is no user.

app authenticates with secret or certificate
> Entra issues app-only token
> app calls API

Use certificates instead of client secrets when possible. For Azure-hosted workloads, prefer managed identity.

Managed Identity

Use this when an Azure resource needs to call another Azure-protected resource.

Azure resource has managed identity
> app asks Azure for token
> no secret stored in code or pipeline

Managed identity is the cleanest option for workloads running in Azure because credential rotation is handled by the platform.

Workload Identity Federation

Use this when an external workload needs Azure access without storing a secret.

Common examples:

GitHub Actions
Azure DevOps pipelines
Kubernetes workloads

The external platform issues a token. Microsoft Entra trusts that token and exchanges it for an Entra access token.

pipeline gets external token
> Entra validates issuer, subject, and audience
> Entra issues access token

This avoids long-lived client secrets in CI/CD.

API Delegation Flow

On-Behalf-Of Flow

Use this when a user signs in to one API and that API needs to call another API as the same user.

user signs in to frontend
> frontend calls API A with user token
> API A exchanges token using on-behalf-of flow
> API A calls API B as the user

Use this for delegated API chains. Do not replace it with app-only permissions unless the downstream call should ignore the user context.

Enterprise SSO Choices

OIDC SSO

OIDC means OpenID Connect.

For modern SaaS and custom apps, OIDC usually uses authorization code flow:

SaaS redirects user to Entra
> Entra returns code to SaaS
> SaaS exchanges code for ID token
> SaaS signs user in

The ID token proves who the user is.

SAML SSO

SAML is common for enterprise SaaS applications.

SaaS redirects user to Entra
> Entra authenticates user
> Entra sends SAML assertion to SaaS
> SaaS signs user in

SAML is older, XML-based, and still widely used for enterprise SSO.

Tokens You Will See

Token or value	What it means
Authorization code	Temporary value returned to the redirect URI and exchanged for tokens
ID token	Proves who the signed-in user is
Access token	Authorizes access to an API
Refresh token	Lets an app get new tokens without asking the user to sign in again
Client secret	Password-like credential for an app; avoid when better options exist
Certificate	Stronger app credential than a secret
Federated credential	Trust relationship for an external workload token

Common Mistakes

• using client credentials when the app should act as a user
• using delegated user flow when no user is present
• storing secrets in CI/CD instead of using federation
• using implicit flow for a new SPA
• confusing app assignment with API permissions
• thinking a successful sign-in proves the app has correct authorization
• requesting broad Graph permissions when only sign-in is needed

Practical Rule

Start with the actor:

User present? -> authorization code, PKCE, or device code
No user? -> client credentials, managed identity, or workload federation
API calls API for user? -> on-behalf-of
SaaS SSO? -> OIDC or SAML
Legacy browser token return? -> implicit/hybrid, avoid for new apps

Most confusion disappears once you separate authentication, consent, app assignment, and API authorization.