Authentication in Azure: SSO, MFA, Passwordless & Conditional Access

In a nutshell

Picture a large office building with a security desk in the lobby. You show your ID once on arrival and get a visitor badge; from then on the badge — not your ID — opens the doors you’re allowed through. The badge is printed for this visit only and quietly expires, and you top it up at the desk without digging your ID out again. Some days the desk wants a second proof first — a fingerprint, or a code on your phone. And a written building policy decides, per visit, whether a badge alone is enough or the sensitive floors need an extra check based on who you are, which entrance you used, and whether anything looks off.

That building is Microsoft Entra ID, and this lesson is about how its security desk works. Your password is your ID — you show it only to the desk, never to the shops and offices inside. The badge is a token — a small signed pass the apps read instead of your password. Topping up the badge is the refresh token. The second proof is multi-factor authentication (MFA), and — better still — passwordless sign-in, where you flash a tamper-proof keycard bound to you that a fake front desk cannot copy. The written building policy is Conditional Access, the engine that grants, challenges, or blocks each sign-in on the signals it can see.

Get this one model straight and the rest of identity clicks into place: apps never touch your secret, access is a short-lived pass that can be revoked, and when to demand a stronger proof is a policy you design.

Level: Intermediate · Time: ~30 min (read + optional lab)

Before you start, be comfortable with what an Entra tenant, user, and group are, and with the split between authentication (“who are you?”) and authorization (“are you allowed to do this here?”). If either is fuzzy, the Entra ID fundamentals lesson covers both.

By the end you will be able to read a sign-in end to end, tell an ID token from an access token, choose the right MFA and passwordless methods, and write a Conditional Access policy without locking anyone out. The full objectives and prerequisites are in the two short sections just below.

You already know that Microsoft Entra ID answers the question “who are you?” and that Azure RBAC answers “are you allowed to do this here?”. This lesson opens up that first door and looks at the machinery behind it. When a user types their name into a sign-in page, a surprising amount happens in the next two seconds: a redirect to Entra ID, a credential check, possibly a second factor, a stack of policy evaluations, and finally the issuing of a small signed pass called a token. Understanding that flow is the difference between an administrator who configures authentication and one who merely enables checkboxes and hopes.

We will build the picture from the protocol up — OAuth 2.0 and OpenID Connect (OIDC) at a level you can actually reason about — then layer on the things organisations care about in practice: single sign-on (SSO), federation, multi-factor authentication (MFA) with number matching, passwordless sign-in (Windows Hello, FIDO2 security keys, the Authenticator app), self-service password reset (SSPR), and the policy engine that ties it all together, Conditional Access. By the end you will be able to read a sign-in log, design an MFA roll-out, and write a Conditional Access policy that grants, challenges, or blocks based on real-world signals.

Learning objectives

By the end of this lesson you can:

• Trace a modern sign-in end to end and name the OAuth2/OIDC pieces involved: identity vs access vs refresh tokens, scopes, and consent.
• Explain single sign-on, and distinguish federation, password hash sync, pass-through authentication, and seamless SSO.
• Choose appropriate MFA methods, and explain why number matching defeats MFA-fatigue attacks.
• Describe passwordless options — Windows Hello for Business, FIDO2 keys, and Authenticator passwordless / passkeys — and why they are phishing-resistant.
• Enable self-service password reset safely and connect it to on-prem password writeback.
• Read Conditional Access as a policy engine: signals → conditions → access controls (grant, require MFA, block, session).

Prerequisites & where this fits

You should already understand tenants, users, groups, and the split between authentication and authorization. If those are new, read Microsoft Entra ID Fundamentals: Tenants, Users, Groups & RBAC first, and make sure you are comfortable in the portal and Azure Cloud Shell. You need an Entra tenant where you hold the Global Administrator or Security Administrator role to follow the lab; a free Entra tenant or an Microsoft 365 developer tenant is perfect. This is the authentication lesson of the Identity module in the Azure Zero-to-Hero course — it sits between the identity fundamentals and the deeper RBAC & governance deep dive, and everything in the security track later assumes you understand it.

Core concepts: tokens, not passwords

The single most important mental shift is this: modern apps never see your password. Your password is a secret shared only between you and Entra ID. Apps receive tokens instead — short-lived, signed JSON documents that prove an authentication happened and describe what the bearer may do. This is why a leaked app database does not leak your credential, and why signing out of one place can be made to sign you out everywhere.

Three token types do almost all the work, and conflating them is the classic beginner mistake:

The distinction is worth saying plainly. The ID token is for the app to learn who the user is — it is an identity assertion, never sent to an API. The access token is the one the app attaches (as a Bearer header) when it calls a downstream API such as Microsoft Graph or your own web API; the API validates it and reads its scopes and roles to decide what to allow. The refresh token never goes to an API at all — it is redeemed back at Entra ID to mint fresh access tokens without re-prompting the user, which is what makes a session feel continuous even though access tokens expire quickly.

A few supporting terms you will meet constantly:

• Scope (or delegated permission) — a string like Files.Read that names a slice of an API the user consents to let the app use on their behalf. App roles / application permissions are the equivalent for an app acting as itself (no user).
• Consent — the one-time (or admin-granted) agreement that an app may request given scopes. Admin consent grants on behalf of the whole tenant; user consent is per user and can be restricted.
• Claims — the key/value facts inside a token (object ID oid, tenant tid, name, group membership, authentication methods, and so on). RBAC, Conditional Access, and your app all read claims.
• Authority / issuer — the Entra endpoint that signs tokens for your tenant, e.g. https://login.microsoftonline.com/<tenant-id>/v2.0. Apps validate a token’s signature (against Entra’s published keys), issuer, audience, and expiry.

How a sign-in actually works (OAuth2/OIDC at a teachable level)

Let us walk a real browser sign-in to a web app using the OIDC authorization-code flow with PKCE — the flow Microsoft recommends for almost everything today. Keep the token table above in mind; this is simply how those tokens get issued.

1. Unauthenticated request. You open app.contoso.com. The app has no valid session, so instead of showing content it redirects your browser to Entra ID’s /authorize endpoint, passing its client ID, the scopes it wants, a redirect URI, and a one-time code challenge (PKCE).
2. Authentication at Entra. Entra now owns the interaction. It collects your username, then your credential (password, or a passwordless gesture), and — if policy requires — a second factor. Crucially, the app is not involved in any of this; your secret stays between you and Entra.
3. Policy evaluation. Before issuing anything, Entra runs Conditional Access: it looks at signals (user, device, location, app, risk) and decides whether to allow, demand MFA, or block. We cover this engine in detail below.
4. Authorization code returned. On success Entra redirects your browser back to the app’s redirect URI with a short-lived, single-use authorization code — not a token. Codes can be safely passed through the browser because they are useless without the next step.
5. Token exchange (back channel). The app’s server calls Entra’s /token endpoint, presenting the code plus the PKCE code verifier (proving it is the same client that started the flow). Entra responds with an ID token, an access token, and usually a refresh token.
6. Session established. The app validates the ID token, learns who you are, and creates its own session. When it needs to call an API, it sends the access token. When that expires, it silently redeems the refresh token for a new one.

That is the whole dance. Two design choices make it secure: tokens that do grant access (access/refresh) travel on the back channel between servers, never exposed to the browser, while the thing that travels on the front channel (the code) is useless on its own. PKCE binds the two halves so a stolen code cannot be redeemed by anyone else.

It is worth naming the legacy alternative you should avoid: ROPC (resource-owner password credentials), where an app collects the password itself and sends it to Entra. It breaks MFA, breaks passwordless, breaks Conditional Access, and trains users to type their password into non-Microsoft screens. Treat it as deprecated. For device-bound and headless scenarios, prefer the device code flow or client credentials (app-only) instead.

Single sign-on (SSO) and federation

Single sign-on means a user authenticates once and then reaches many applications without re-entering credentials. In the Entra world this works because Entra ID issues a primary session (a cookie/token in the browser, or a Primary Refresh Token on a registered device). When the next app redirects to /authorize, Entra sees that valid session and issues fresh app tokens silently — no second prompt. The user experiences “I logged in to my laptop this morning and everything just works.”

How SSO is delivered depends on the app’s protocol and where the password is checked. The key distinction for interviews is managed authentication (Entra checks the credential) versus federated authentication (a different identity provider checks it and Entra trusts the result).

A few clarifications that trip people up:

• Federation specifically means delegating the credential check to another identity provider. Entra does not see the password; the IdP authenticates the user and returns a signed SAML assertion (or token) that Entra trusts because of a configured trust relationship. Historically this was AD FS; Microsoft now steers most customers away from AD FS toward cloud authentication (PHS/PTA) because AD FS is extra infrastructure to secure and patch, and it sits squarely in the attack path.
• Seamless SSO is not a credential method — it is a convenience that sits on top of PHS or PTA. On a domain-joined machine on the corporate network, the browser obtains a Kerberos ticket and Entra accepts it, so the user is signed in with no prompt at all. On modern Entra-joined or hybrid-joined Windows, the Primary Refresh Token (PRT) does the same job more robustly and is the preferred path.
• App-side SSO protocols. Modern apps use OIDC/OAuth; older enterprise apps use SAML 2.0 or WS-Federation. Entra speaks all of them, which is how one identity can front a SaaS estate with mixed protocols. You configure these per app in Enterprise applications.

The practical upshot: for almost all new hybrid deployments, choose Password Hash Sync + Seamless SSO (or rely on PRT for Entra-joined devices). Reach for PTA only when a hard policy says passwords may never be evaluated in the cloud, and reach for federation only when you have a concrete requirement an IdP uniquely satisfies.

Multi-factor authentication (MFA)

A password is something you know; on its own it is a single point of failure that phishing, reuse, and breaches defeat daily. MFA demands a second, independent factor — something you have (a phone, a key) or something you are (a fingerprint or face) — so a stolen password alone is not enough. In Entra ID, MFA is no longer a standalone toggle: you choose which methods are allowed in the Authentication methods policy, and you decide when MFA is required using Conditional Access (modern) rather than the legacy per-user MFA switch.

The available methods differ enormously in strength. Treat this table as a ranking, strongest at the top:

Number matching — why it matters

The original Authenticator “Approve/Deny” push had a fatal weakness: an attacker who had the user’s password could spam approval prompts until a tired or distracted user tapped Approve — an MFA-fatigue (or “push bombing”) attack. Number matching closes this. Now the sign-in screen shows a two-digit number that the user must type into the Authenticator app to approve. Because the number lives on the screen the attacker triggered — not on the user’s phone — the user cannot approve a sign-in they did not start. Entra layers on additional context (app name and geographic location of the request) so the user sees what they are approving. Number matching is now enforced by default for Authenticator push, and you should never disable it.

Configuring MFA the modern way

The recommended architecture is: enable strong methods in the Authentication methods policy, then require MFA via Conditional Access for the right users and conditions. Avoid the deprecated per-user MFA (the old “enabled/enforced” state on each account) and the legacy Security Defaults once you are large enough to need targeted policy — Security Defaults is a fine free baseline for small tenants, but it is all-or-nothing.

Passwordless authentication

MFA still typically involves a password. Passwordless removes the password entirely — the user proves possession of a device plus a biometric or PIN, and there is no shared secret to phish, reuse, or breach. This is the strategic direction Microsoft (and the industry, via the FIDO Alliance) is pushing, and it is the single highest-impact security improvement most organisations can make. Three Entra-native options:

• Windows Hello for Business. On a Windows PC, the user enrols a biometric (face/fingerprint) or PIN that unlocks a private key held in the device’s TPM (a tamper-resistant chip). The private key never leaves the hardware; sign-in is a cryptographic challenge bound to that device. The PIN feels like a password but is not — it is local to the device and useless anywhere else, which is why a “PIN” here is far stronger than a password.
• FIDO2 security keys. A small hardware key (USB/NFC) holds the private key. The user touches the key and provides a gesture (PIN/biometric on the key). Because authentication is bound to the origin (the real Entra domain) by the WebAuthn protocol, a FIDO2 key cannot be used against a look-alike phishing site — this is what “phishing-resistant” means concretely. Ideal for shared workstations and high-value admins.
• Microsoft Authenticator passwordless / passkeys. The user’s phone becomes the credential: they enter their username, the app prompts for a biometric, and number matching confirms the request. Modern Authenticator supports device-bound passkeys, giving phishing resistance with the convenience of the phone people already carry.

Why phishing-resistant beats “MFA”. A push-approval or one-time code can still be relayed by an attacker-in-the-middle proxy (the user is tricked into approving the attacker’s session). FIDO2, Windows Hello, and passkeys defeat this because the credential is cryptographically bound to the legitimate website’s origin — there is nothing for the user to hand over and nothing the proxy can replay. When a security baseline says “require phishing-resistant MFA for admins,” it means these methods, not SMS or basic push.

Self-service password reset (SSPR)

People forget passwords, and a forgotten password should not mean a help-desk ticket and an hour of lost work. SSPR lets users reset or unlock their own account after proving identity through registered methods (Authenticator, phone, email, security questions). It reduces help-desk load, removes a social-engineering vector (attackers calling the help desk to reset accounts), and improves user experience.

Key things to get right:

• Scope and method count. Enable SSPR for a pilot group first, then all users. Require two methods to reset (one is too weak), and prefer app/phone over security questions, which are guessable.
• Combined registration. Turn on the combined security-information registration experience so users register their MFA and SSPR methods once, in one place — far less confusing than two separate enrolments.
• Password writeback. In a hybrid environment, enable password writeback in Entra Connect so a cloud reset flows back to on-prem Active Directory. Without it, a user who resets in the cloud would still have the old password on the corporate network — a recipe for lockouts.
• Admin accounts. Microsoft enforces SSPR-style strong reset for administrator roles automatically; do not rely on it as your only protection for privileged accounts — pair it with phishing-resistant MFA and PIM.

Conditional Access: the policy engine

If MFA and passwordless are the capabilities, Conditional Access (CA) is the brain that decides when to use them. It is best understood as a simple sentence Entra evaluates on every sign-in:

WHEN these assignments (signals) are true, THEN apply these access controls.

The model has two halves — what the policy matches on, and what it does.

Assignments (the signals / conditions it matches on):

Access controls (what it does when matched):

• Grant controls — Block access outright, or Grant access only if one or more requirements are met: require MFA, require phishing-resistant MFA / authentication strength, require compliant device, require Entra-hybrid-joined device, require approved client app, require app protection policy, require password change. You combine these with require all or require one.
• Session controls — shape how long and how the session behaves: sign-in frequency (force re-auth every N hours), persistent browser session (allow/never), app-enforced restrictions, and routing through Defender for Cloud Apps for in-session monitoring.

Reading a policy

A real “baseline” policy reads naturally once you know the shape. For example: WHEN any user (excluding the two break-glass accounts) signs in to any cloud app from any location, THEN grant access only if they complete MFA. That single policy is the backbone of most tenants. A second classic: WHEN a user accesses the Microsoft Azure Management app, THEN require a compliant device AND phishing-resistant MFA — locking the control plane down hard while leaving everyday apps a touch more relaxed.

Three operational rules will save you grief:

1. Policies are additive and the most restrictive wins. If any applicable policy says block, the user is blocked, regardless of other grants. Plan for the combination, not each policy in isolation.
2. Always exclude break-glass accounts. Keep two emergency-access accounts (no MFA dependency, long random passwords in a vault, heavily monitored) excluded from your CA policies so a misconfigured policy cannot lock everyone, including admins, out of the tenant.
3. Use Report-only mode first. Every new policy supports Report-only, which evaluates and logs the outcome without enforcing it. Run a policy in report-only for a few days, inspect the sign-in logs to see who would have been affected, then flip it to On. This is the single best habit for avoiding self-inflicted outages.

Putting the whole picture together: a sign-in arrives, Entra authenticates the credential (ideally passwordless), Conditional Access weighs the signals and may demand a step-up (phishing-resistant MFA) or block, and only then are tokens issued. The diagram below shows that pipeline end to end.

The flow makes the layering explicit: the OIDC redirect, the credential and second-factor check, the Conditional Access decision point fed by user/device/location/risk signals, and the final token issuance with its three token types.

Hands-on lab: enable phishing-resistant MFA with a Conditional Access policy

In this lab you will allow strong authentication methods and then require MFA for a pilot group with a Conditional Access policy — created safely in Report-only mode first. Most of this is portal-driven because Conditional Access is best learnt in the UI, but we use the CLI to set up a test group and inspect results.

You need: a tenant where you are Global Administrator (or Security Administrator + Authentication Policy Administrator), and at least one non-admin test user. A free or developer tenant is fine. Conditional Access requires Entra ID P1; developer/M365 E5 trial tenants include it.

1. Create a pilot group and add a test user

In Cloud Shell:

# Create a security group for the pilot
az ad group create \
  --display-name "ca-mfa-pilot" \
  --mail-nickname "ca-mfa-pilot"

# Find your test user's object id (replace the UPN)
az ad user show --id "testuser@yourtenant.onmicrosoft.com" --query id -o tsv

# Add the user to the group (use the id from above)
az ad group member add \
  --group "ca-mfa-pilot" \
  --member-id "<user-object-id>"

Expected: the group is created and az ad group member list --group ca-mfa-pilot -o table shows your test user.

2. Allow strong authentication methods

In the Entra admin centre → Protection → Authentication methods → Policies:

• Enable Microsoft Authenticator and set it to All users; confirm number matching and additional context are enabled (they are on by default).
• Enable FIDO2 security key (and Passkeys) for the pilot group if you have a key to test.
• Leave SMS disabled (or restrict it) so the pilot uses strong methods only.

3. Create the Conditional Access policy in Report-only

In Entra admin centre → Protection → Conditional Access → + New policy:

1. Name: CA001 – Pilot: require MFA.
2. Users: Include the ca-mfa-pilot group. Under Exclude, add your break-glass accounts (create two if you have none).
3. Target resources: All cloud apps (or pick one test app).
4. Grant: Grant access → tick Require multifactor authentication → Require one of the selected controls.
5. Enable policy: set to Report-only.
6. Create.

4. Test and read the result

Sign in as the test user in a private browser window. Because the policy is report-only, the user is not challenged, but the evaluation is recorded. Now inspect it:

• Entra admin centre → Monitoring → Sign-in logs → open the test user’s sign-in → the Conditional Access tab. You will see CA001 with a result of Report-only: would have required MFA (or success if the user is already MFA-registered).

This confirms the policy targets the right user and would take the right action — without having risked locking anyone out.

5. Promote to enforcement (optional)

Once the report-only results look correct, edit the policy and set Enable policy to On. Sign in again as the test user — this time you are prompted to register/complete MFA. Confirm the sign-in log now shows Success – MFA requirement satisfied.

Cleanup

# Remove the test user from the group, then delete the group
az ad group member remove --group "ca-mfa-pilot" --member-id "<user-object-id>"
az ad group delete --group "ca-mfa-pilot"

In the portal, delete (or return to Report-only/Off) the CA001 policy so it does not affect real users. Leave the Authentication methods policy as-is if you want to keep strong methods enabled.

Cost note

There is no charge for the objects you created. Conditional Access, risk-based policies, and passwordless at scale require Entra ID P1/P2 licences, which are included in the free developer/E5 trial used here; in production they are part of P1 (CA, SSPR for cloud users) and P2 (risk-based CA, Identity Protection, PIM). Basic MFA via Security Defaults is free for all tenants.

Going deeper

Everything above is the model an administrator needs. This section is for the engineer who has to make it survive production — token internals, session mechanics, revocation, and the identity RBAC that decides who can even touch these controls.

What is actually inside a token (and which ones you must never validate)

An Entra token is a JWT — three base64url segments, header.payload.signature. The header names the signing key with a kid; the payload is the claims; the signature is Entra signing over the first two parts. Your API validates a token by fetching Entra’s public keys (from the tenant’s OIDC discovery document → jwks_uri), picking the key whose kid matches, and checking the signature, issuer (iss), audience (aud), and time window (nbf ≤ now < exp); ID tokens also carry a nonce to check. A decoded ID token (illustrative — real JWTs carry no comments):

{
  "aud": "11111111-1111-1111-1111-111111111111",     // the CLIENT app id — an ID token is FOR the app
  "iss": "https://login.microsoftonline.com/<tenant-id>/v2.0",
  "iat": 1718900000, "nbf": 1718900000, "exp": 1718903600,
  "name": "Ada Lovelace",
  "oid": "22222222-2222-2222-2222-222222222222",      // stable, per-tenant user object id
  "preferred_username": "ada@contoso.com",
  "tid": "<tenant-id>", "nonce": "<nonce-your-app-sent>",
  "amr": ["pwd", "mfa"], "ver": "2.0"
}

The most common token bug in the wild: do not decode or validate Microsoft Graph access tokens. Tokens Entra issues for Graph are Microsoft’s private contract — they may be opaque or encrypted and carry a nonce only Graph can process, so validating one yourself fails or misleads. Validate only access tokens for an API you own, where aud is your API’s app ID URI/client id and scp (delegated scopes) or roles (app roles) says what is authorised. Mind the version: the v1.0 endpoint issues iss of https://sts.windows.net/<tid>/, v2.0 issues .../v2.0, and an API’s accessTokenAcceptedVersion must match or valid tokens are rejected as the wrong audience.

Sessions, the Primary Refresh Token, and why “sign out” is subtle

On a registered/joined Windows device, Entra issues a Primary Refresh Token (PRT) bound to the device by a session key sealed in the TPM — so it cannot be lifted onto another machine — and carrying the MFA claim, which is why one MFA on a device lets later app sign-ins proceed silently. The browser rides it through a signed x-ms-RefreshTokenCredential cookie; native apps use WAM. This is the machinery behind “I logged in this morning and everything just works.”

It also explains why disabling an account doesn’t instantly cut access: access tokens are self-contained and valid until exp (roughly an hour, randomised so fleets don’t renew in lockstep). The old Configurable Token Lifetime policies for access/ID tokens were retired, so you can’t just “make tokens shorter” — the levers are Conditional Access sign-in frequency and CAE.

Continuous Access Evaluation — near-real-time revocation

CAE makes the resource an active participant. A CAE-capable client advertises the capability with an xms_cc claim; a CAE-capable resource (Graph, Exchange Online, SharePoint) keeps a channel with Entra and, on a critical event — account disabled/deleted, password reset, token revocation, or elevated user risk from Identity Protection — rejects the token with a claims challenge (HTTP 401 + WWW-Authenticate: ... claims=...). The client takes that back to Entra, which re-evaluates CA and reissues or blocks — so revocation lands in minutes instead of at token expiry, and CAE can enforce location continuously. It only helps where both ends support it; legacy clients and non-CAE APIs still ride the token to exp.

Authentication strengths — how “require phishing-resistant MFA” is enforced

A Conditional Access grant that says require authentication strength points at a named authentication strength: an enforceable set of allowed method combinations. Three are built in — Multifactor authentication, Passwordless MFA, Phishing-resistant MFA — and a custom strength can list exact combinations (say, FIDO2 or certificate-based auth only). At sign-in Entra compares the methods actually satisfied against the requirement and forces a step-up if they fall short. For guest (B2B) users the home tenant usually performs MFA; whether you accept it depends on cross-tenant access settings, where you choose to trust MFA and compliant-device claims from the guest’s home tenant instead of re-prompting.

Who is allowed to configure any of this

These controls are high-value targets, so grant them by least-privilege directory role, not Global Administrator:

Manage CA policy as code through the Microsoft Graph identity/conditionalAccess/policies endpoint, keeping the JSON in source control so every change is a reviewed pull request with a rollback.

Passkeys: device-bound vs synced, and where Entra stands

A passkey is a discoverable FIDO2 credential, and the enterprise-critical question is where the private key can go. A device-bound passkey (hardware key, Windows Hello, or a passkey in Microsoft Authenticator) keeps the private key on one authenticator — it never leaves. A synced passkey (iCloud Keychain, Google Password Manager) backs the key up to a cloud keychain and shares it across a user’s devices — convenient for consumers, a different assurance story for a regulated enterprise. In Entra today, device-bound passkeys in Authenticator and hardware FIDO2 keys are generally available; broader synced-passkey support is newer and rolling out, so confirm its current state before depending on it. Where hardware-bound assurance matters, restrict the FIDO2 policy to approved models by their AAGUID allow-list and require attestation — otherwise any consumer or software passkey satisfies “phishing-resistant.”

Failure modes to design for at scale

• Signing-key rollover. Entra rotates keys; a service that hardcodes one breaks at the next rotation. Cache by kid and refetch the JWKS on an unknown kid.
• Clock skew. Allow a couple of minutes’ leeway on exp/nbf, or valid tokens fail on a drifted server.
• Legacy auth leaking in. SMTP AUTH, EWS, and old clients bypass most CA controls and surface in the logs as client app = “Other clients” — block them with a dedicated policy.
• Federation outage with no fallback. If AD FS or the PTA agent is down and you never staged Password Hash Sync, nobody signs in. Keep PHS enabled as a backstop; if you’re moving off AD FS, see Migrate AD FS to Entra ID authentication and Entra Connect Sync to cloud sync.
• Break-glass blind spots. The emergency accounts are excluded from CA by design, so CA can’t protect them — alert on every sign-in they make, keep long random secrets in a vault, and add a FIDO2 key where possible. Pair with the detections in Defender for Identity.

Common mistakes & troubleshooting

Best practices

• Make passwordless the default, not the exception. Roll out Windows Hello for Business and passkeys/FIDO2; reserve passwords for break-glass only over time.
• Drive MFA through Conditional Access, not per-user toggles, so requirements are targeted, auditable, and consistent — and always start new policies in Report-only.
• Block legacy authentication. It is the most common bypass of every modern control; a single CA policy closes it.
• Eliminate weak factors. Phase out SMS and voice for anything privileged; require phishing-resistant methods (authentication strengths) for admins and the Azure Management app.
• Use combined registration and roll SSPR + MFA enrolment into one user journey.
• Keep two break-glass accounts, excluded from CA, with long random secrets in a vault, alerted on every use.
• Prefer cloud authentication (PHS). It is resilient to on-prem outages and removes AD FS as an attack surface; keep PHS enabled even alongside federation as a fallback.

Security notes

Identity is the real perimeter, and authentication is its front door. Three points deserve emphasis. First, phishing-resistant MFA is categorically stronger than “MFA” — only origin-bound credentials (FIDO2, Windows Hello, passkeys, CBA) defeat real-time relay/AiTM phishing; treat SMS and basic push as legacy. Second, tokens are bearer credentials — anyone holding a valid access or refresh token is the user until it expires, so protect them: enable token protection, shorten sign-in frequency for sensitive apps, and use Continuous Access Evaluation so events like a disabled account or risky sign-in revoke access in near-real-time rather than waiting for token expiry. Third, privileged accounts need the most, not the least, friction — require phishing-resistant MFA, gate them behind Conditional Access, and grant their roles just-in-time with PIM rather than standing access. For the deeper hardening playbook see Conditional Access Token Protection and Just-in-Time Access with PIM.

Common beginner mistakes

These are conceptual traps — wrong mental models rather than broken configs. (The symptom-to-fix table above handles “it’s not working”; this is about thinking correctly.)

• “Passwordless is just MFA with extra steps.” MFA adds a factor on top of a password, so a phishable secret stays in the mix; passwordless removes the password. And phishing-resistance is a separate axis from factor count — it comes from binding the credential to the site’s origin (WebAuthn), not from having two factors. Right model: factors and phishing-resistance are two different dials.

• “Turn on per-user MFA and you’re done.” The old per-user “enabled/enforced” toggle is legacy and fights Conditional Access — a user stuck in per-user enforced is prompted even when CA wouldn’t ask. Right model: drive the requirement through Conditional Access (or Security Defaults on a tiny tenant), leaving per-user MFA off.

• “The access token tells my app who the user is.” Reading identity from an access token — or validating a Graph access token — is backwards. Right model: the ID token identifies the user to your app; the access token authorises calls to an API and is validated by that API.

• “Forcing password changes every 90 days is good hygiene.” Scheduled expiry breeds Summer2026! → Autumn2026! patterns and buys little. Right model (current Microsoft/NIST guidance): drop mandatory rotation; deploy phishing-resistant passwordless, banned-password protection, and Conditional Access, and rotate on evidence of compromise.

• “SMS codes are fine — it’s still a second factor.” Treating all MFA as equal is the trap. SMS and voice are defeated by SIM-swap, SS7 interception, and real-time phishing relays. Right model: SMS is MFA but not phishing-resistant — a low-risk fallback at most, never for admins or the Azure control plane.

• “CA policies run top-to-bottom and first match wins.” There is no ordering. Right model: every applicable policy is evaluated and the results combined — if any says block, the user is blocked; all grant controls across matching policies must be satisfied together. Use What-If to see the combination.

• “Report-only means the policy is off.” It looks inert because users aren’t challenged, but report-only fully evaluates and logs what would have happened — your safety net for validating impact before enforcing. “Off” is a separate third state.

• “I’ll run Conditional Access and keep Security Defaults on, for belt-and-braces.” They don’t stack. Right model: Security Defaults and Conditional Access are mutually exclusive — turn Security Defaults off or your CA policies quietly do nothing.

Practice challenges

Work these in order — they climb from “read a token” to “prove revocation lands in minutes.” Use a free or developer tenant; nothing here charges money. Try each before opening the solution.

1. (Beginner) Tell an ID token from an access token. Capture the two tokens your app receives at sign-in (or grab any sample) and paste each into jwt.ms. Without reading the docs, decide which is which.

<details> <summary>Solution</summary>

Look at two claims. The ID token has aud equal to the client app’s id and no scp. The access token has aud equal to a resource (an API’s app ID URI or client id) and carries scp (delegated scopes) or roles. If you see scp, it’s an access token.

Why: audience and scope encode the token’s job — identity for the app vs authorisation for an API. </details>

2. (Beginner) Find every phishing-resistant method your tenant allows. In the Entra admin centre, list the enabled authentication methods and mark which are phishing-resistant.

<details> <summary>Solution</summary>

Protection → Authentication methods → Policies. The phishing-resistant ones are FIDO2 security key, Windows Hello for Business, passkeys in Authenticator, and certificate-based authentication. Authenticator push (even with number matching), TOTP, SMS, and voice are not phishing-resistant.

Why: only origin-bound (WebAuthn/certificate) credentials survive an attacker-in-the-middle relay. </details>

3. (Intermediate) Block legacy authentication. Describe the Conditional Access policy that shuts the biggest MFA bypass, and how you’d ship it safely.

<details> <summary>Solution</summary>

New CA policy → Users: all users, exclude the two break-glass accounts → Target resources: all cloud apps → Conditions → Client apps: tick Exchange ActiveSync clients and Other clients → Grant: Block access. Create it in Report-only, confirm in the sign-in logs (client app = Other clients) that only legacy traffic matches, then flip to On.

Why: legacy protocols can’t do MFA or honour most CA controls, so blocking them closes the prime password-spray path — report-only first proves you won’t strand a real client. </details>

4. (Intermediate) Require a specific strong method on the control plane. Build an authentication strength that accepts only FIDO2 or certificate-based auth, and apply it to the Azure management plane in report-only.

<details> <summary>Solution</summary>

Protection → Authentication methods → Authentication strengths → New → include only FIDO2 security key and Certificate-based authentication (multifactor). Then a CA policy: Target resources → Microsoft Azure Management, Grant → Require authentication strength → your custom strength, Report-only. Read the sign-in logs to see who would be forced to step up.

Why: “require MFA” would still accept SMS; a custom strength pins the control plane to phishing-resistant methods only, without touching everyday apps. </details>

5. (Advanced) Kill the “why am I prompted for MFA all day?” complaints. A user on a managed laptop is challenged for MFA several times a day. Diagnose it and design a fix that keeps security intact.

<details> <summary>Solution</summary>

Check the sign-in logs: repeated interactive MFA usually means no durable session — the device isn’t Entra-registered/joined (no PRT to carry the MFA claim), sign-in frequency is too aggressive, or persistent browser session is off. Fix: get the device Entra-joined/hybrid-joined so a PRT gives silent SSO, set sign-in frequency to a sane window (hours, not minutes) for normal apps, and allow persistent browser session — keeping the control plane tighter.

Why: the PRT is what lets one MFA satisfy many app sign-ins; without a registered device every app re-prompts. You tune friction by resource sensitivity, not globally. </details>

6. (Advanced) Prove near-real-time revocation. Show that disabling an account cuts its access within minutes, not an hour, and verify it.

<details> <summary>Solution</summary>

Confirm CAE is on (default) and the client is CAE-capable (current Outlook/Teams/OneDrive against Graph/Exchange/SharePoint). Sign the test user in, then disable the account. Within minutes the next call is refused with a claims challenge and the client is bounced back to Entra, which blocks. Verify in Sign-in logs that the token was rejected — you don’t wait out the ~1-hour lifetime.

Why: CAE makes the resource reject tokens on critical events instead of trusting them until exp, which is the difference between “revoked now” and “revoked eventually.” </details>

Interview & exam questions

1. What is the difference between an ID token and an access token? The ID token (OIDC) is for the client application to learn who signed in — an identity assertion with claims like name and object ID; it is never sent to an API. The access token (OAuth2) is sent to a resource/API as a Bearer credential and carries the scopes/roles that authorise specific operations. The API validates the access token; the app reads the ID token.

2. What does a refresh token do, and why is it kept separate? A refresh token is redeemed at Entra’s token endpoint to obtain new access (and ID) tokens silently, so a session continues past the short life of an access token. It is kept on the back channel and never sent to APIs, limiting exposure; access tokens are deliberately short-lived precisely because refresh tokens can renew them.

3. Explain the OIDC authorization-code flow with PKCE in one breath. The app redirects the browser to Entra’s /authorize with a code challenge; the user authenticates and Conditional Access is evaluated; Entra returns a single-use authorization code to the redirect URI; the app’s server exchanges the code plus the PKCE verifier at /token for ID, access, and refresh tokens. Codes travel the front channel (useless alone); tokens travel the back channel; PKCE binds the two halves.

4. What is federation, and how does it differ from password hash sync? Federation delegates the credential check to an external IdP (e.g. AD FS) that returns a signed assertion Entra trusts — Entra never sees the password. Password hash sync synchronises a hash of the password hash to the cloud and lets Entra verify sign-ins directly. PHS is simpler and resilient to on-prem outages; federation adds infrastructure and an attack surface, so Microsoft recommends cloud authentication for most cases.

5. What is seamless SSO and what does it depend on? Seamless SSO silently signs in users on domain-joined machines on the corporate network, using Kerberos to obtain a ticket Entra accepts. It is not a credential method — it rides on PHS or PTA. On modern Entra-joined/hybrid-joined Windows, the Primary Refresh Token (PRT) provides equivalent silent SSO more robustly.

6. Why does number matching matter? It defeats MFA-fatigue / push-bombing: instead of a simple Approve/Deny, the user must type a number shown on the sign-in screen into Authenticator. Because that number lives on the screen the attacker triggered, a user cannot approve a sign-in they did not initiate. It is enforced by default and should never be disabled.

7. What makes an authentication method “phishing-resistant”? The credential is cryptographically bound to the legitimate site’s origin (WebAuthn/FIDO2), so it cannot be entered into, or relayed through, a look-alike phishing site or an attacker-in-the-middle proxy. FIDO2 keys, Windows Hello for Business, passkeys, and certificate-based auth qualify; SMS, voice, and basic push do not.

8. Describe the Conditional Access model. CA evaluates assignments (signals: users/groups, target resources, location, device platform/state, client app, sign-in risk) and applies access controls (grant with requirements like MFA / compliant device / phishing-resistant strength, block, or session controls like sign-in frequency). Policies are additive and the most restrictive wins; always exclude break-glass accounts and pilot in Report-only.

9. A new CA policy must not lock anyone out. What two safeguards do you use? Report-only mode to evaluate and log impact before enforcing, and break-glass account exclusions so emergency admins can always sign in even if a policy is misconfigured.

10. When would you choose pass-through authentication over password hash sync? When organisational policy mandates that passwords are never evaluated or stored (even as a hash) in the cloud, and live validation against on-prem AD is required. The trade-off is a dependency on the PTA agent/DC being reachable; Microsoft still recommends enabling PHS as a fallback for resilience.

11. What is the risk of leaving legacy authentication enabled? Legacy protocols (POP, IMAP, SMTP, older Office clients) cannot perform MFA or honour most Conditional Access controls, so they are the prime path for password-spray and credential-stuffing attacks. Block them with a dedicated CA policy.

12. How can access be revoked faster than token expiry? Use Continuous Access Evaluation (CAE), which lets resources react to critical events (account disabled, password reset, risky sign-in, location change) by rejecting tokens in near-real-time, and use sign-in frequency plus explicit session revocation rather than waiting up to an hour for an access token to lapse.

Quick check

1. Which token does an API validate to authorise a call — ID, access, or refresh?
2. Is seamless SSO a way of checking credentials? What does it depend on?
3. Name two phishing-resistant authentication methods.
4. In Conditional Access, what does Report-only mode do?
5. Why must break-glass accounts be excluded from Conditional Access policies?

Answers

1. The access token — the API checks its audience and scopes/roles. The ID token is for the client app; the refresh token is only ever sent back to Entra.
2. No. Seamless SSO is a silent sign-in convenience that rides on PHS or PTA; it uses Kerberos on the corporate network (or, on modern devices, the PRT) and does not itself verify the password.
3. Any two of: FIDO2 security key, Windows Hello for Business, passkeys in Authenticator, certificate-based authentication.
4. It evaluates the policy and logs what would have happened, without enforcing it — so you can verify impact in the sign-in logs before turning it on.
5. So a misconfigured or overly strict policy cannot lock everyone, including all administrators, out of the tenant; the excluded emergency accounts provide a guaranteed recovery path.

Exercise

Design (on paper, then build in Report-only) a two-policy baseline for a small company. Policy A: require MFA for all users, excluding two break-glass accounts, for all cloud apps. Policy B: require a compliant device and phishing-resistant MFA when accessing the Microsoft Azure Management app. Create both in Report-only, sign in as a test user touching the Azure portal, then open the sign-in logs → Conditional Access tab and write one sentence for each policy explaining whether it matched and what it would have enforced. Explain in two sentences why Policy B is stricter than Policy A and why that asymmetry is correct.

Certification mapping

Glossary

• OAuth 2.0 — the authorization framework that issues access and refresh tokens so apps can call APIs on a user’s behalf.
• OpenID Connect (OIDC) — an identity layer on top of OAuth 2.0 that adds the ID token proving who signed in.
• ID / access / refresh token — identity assertion for the app; API authorisation credential; silent-renewal credential redeemed at Entra.
• PKCE — Proof Key for Code Exchange; binds the authorization code to the client that started the flow, blocking code interception.
• Scope / app role — a delegated permission a user consents to; an application permission an app holds acting as itself.
• Single sign-on (SSO) — authenticate once, reach many apps without re-prompting.
• Federation — delegating the credential check to an external identity provider (e.g. AD FS) that Entra trusts.
• PHS / PTA — Password Hash Sync (Entra verifies in the cloud) / Pass-Through Authentication (on-prem agent verifies).
• Seamless SSO / PRT — silent corporate-network sign-in via Kerberos; the device-bound Primary Refresh Token that enables modern silent SSO.
• MFA — multi-factor authentication: requiring a second, independent factor beyond the password.
• Number matching — typing a screen-shown number into Authenticator to approve, defeating MFA-fatigue attacks.
• Passwordless — sign-in with no password at all (Windows Hello, FIDO2, passkeys), removing the secret to phish.
• Phishing-resistant — a credential cryptographically bound to the real site’s origin, immune to relay/AiTM phishing.
• SSPR — self-service password reset; password writeback flows a cloud reset back to on-prem AD.
• Conditional Access — Entra’s policy engine: assignments (signals) → access controls (grant / block / session).
• Break-glass account — an emergency-access admin account excluded from Conditional Access for guaranteed recovery.
• Continuous Access Evaluation (CAE) — near-real-time revocation of access in response to critical security events.
• JWT (JSON Web Token) — the signed token format Entra issues: header.payload.signature, base64url-encoded, validated against Entra’s published keys.
• Claim — a key/value fact inside a token (e.g. oid user id, tid tenant, aud audience, amr methods used). RBAC, Conditional Access, and your app all read claims.
• JWKS / kid — Entra’s published set of public signing keys; the token header’s kid selects which key validates the signature. Keys rotate, so fetch them dynamically.
• amr (authentication methods reference) — the claim listing how the user proved identity this session, e.g. pwd, mfa, fido.
• Authentication strength — a named, enforceable set of allowed method combinations (built-in: MFA, Passwordless MFA, Phishing-resistant MFA; or custom) that a Conditional Access grant can require.
• WebAuthn / FIDO2 — the browser/OS standard that binds a credential to the site’s origin; the reason FIDO2 keys, passkeys, and Windows Hello are phishing-resistant.
• Passkey — a discoverable FIDO2 credential; device-bound (private key stays on one authenticator) or synced (backed up to a cloud keychain and shared across devices).
• AAGUID / attestation — the identifier for an authenticator model, and the proof of which model created a credential; together they let you allow-list approved security keys.
• ROPC — the legacy resource-owner-password flow where an app collects the password itself; breaks MFA, passwordless, and Conditional Access — avoid it.
• Security Defaults — the free, all-or-nothing baseline of identity protections for small tenants; mutually exclusive with Conditional Access.
• Cross-tenant access settings — the B2B controls that decide whether your tenant trusts MFA and compliant-device claims asserted by a guest’s home tenant.

Next steps

Now that you understand the authentication door, learn how Azure decides what an identity may do once inside. Continue with Microsoft Entra & Azure RBAC: Governance Deep Dive — roles, scopes, custom roles, PIM, and governance at enterprise scale. Then deepen your security:

• Conditional Access Token Protection — stop token theft and AiTM relay with authentication context and protected actions.
• Just-in-Time Access: PIM for Azure Roles & Groups — replace standing admin privilege with time-bound, audited elevation.
• Eliminating Secrets: Key Vault & Workload Identity Federation — remove long-lived credentials so workloads authenticate without stored secrets.