How Authentication Actually Works

What happens when a user signs in

When a user opens Outlook and clicks "Sign in," a sequence of events unfolds that most administrators never see. Understanding this sequence is the foundation for every identity security control in this course — because every attack targets a specific point in this flow, and every defense protects a specific point.

The authentication flow follows the OAuth 2.0 and OpenID Connect standards. These aren't Microsoft-specific — they're industry standards used by every major cloud provider. Microsoft's implementation adds risk evaluation, Conditional Access enforcement, and token binding that are specific to Entra ID, but the underlying protocol is standard.

Here is the flow, step by step. The user opens an application — Outlook, Teams, or a browser pointed at portal.office.com. The application doesn't handle authentication itself. It redirects the user's browser to the Entra ID authorization endpoint at login.microsoftonline.com. This redirect includes the application's client ID, the requested permissions, and a redirect URI.

Entra ID presents the sign-in page. The user enters their email address, which identifies the tenant. Entra ID determines which authentication methods are available and presents the appropriate challenge — a password prompt, a passwordless prompt, or a federated redirect to a third-party identity provider.

The user completes primary authentication. Entra ID then evaluates every Conditional Access policy that applies to this sign-in. This is the critical enforcement point. The evaluation considers the user's identity, group memberships, the application being accessed, the device platform and compliance state, the network location (named locations, trusted IPs, country), the sign-in risk level from Identity Protection, and the user risk level. Based on this evaluation, Entra ID either grants access, requires additional authentication, blocks the sign-in entirely, or applies session controls like token protection or sign-in frequency.

Conditional Access evaluation happens before any tokens are issued. This matters because it means the attacker who captures a session token through AiTM phishing has already passed the Conditional Access evaluation — the token they hold has been approved by every policy. That's why the design of Conditional Access policies is so critical: they are the last enforcement point before access is granted, and they must be designed to catch the specific attack technique in use.

If MFA is required, the user completes the second factor — approves a push notification, enters a TOTP code, taps a FIDO2 key, or completes a passkey authentication. The authenticationDetails array in the sign-in log records exactly which methods were used and in which order. This array is the forensic record you use to determine whether a sign-in used phishing-resistant authentication or a method vulnerable to interception.

After all requirements are satisfied, Entra ID issues an authorization code — a short-lived, single-use code valid for approximately 10 minutes. The application exchanges this code at the token endpoint for three tokens: an access token, a refresh token, and an ID token. This exchange is the final step before the user gains access, and the tokens returned are the credentials that the application — and any attacker who intercepts them — uses going forward.

The tokens: what they are and why attackers want them

The three tokens returned at step 9 have entirely different purposes, lifetimes, and value to an attacker.

The access token is a short-lived bearer token that the application presents to APIs. In Entra ID, the default lifetime is variable — 60 to 90 minutes, averaging 75 minutes. For tenants with Continuous Access Evaluation (CAE) enabled, access tokens can have extended lifetimes of 20 to 28 hours because CAE provides real-time revocation capability. Access tokens cannot be refreshed — when they expire, the application must use the refresh token to obtain a new one. An attacker who steals an access token has a narrow window to use it, but during that window, the token grants full access to whatever API it was issued for.

Continuous Access Evaluation changes the security model for access tokens. Without CAE, an access token is a bearer credential — whoever holds it can use it, and revocation only takes effect when the token naturally expires. With CAE, the resource provider (Exchange Online, SharePoint, Teams) checks with Entra ID for critical events in near-real-time: user disabled, password changed, high-risk session detected, network location changed from a trusted to an untrusted range. If a critical event has occurred, the resource rejects the access token even though it hasn't expired. This is why CAE-enabled tokens can safely have longer lifetimes — the real-time revocation capability compensates for the extended validity window.

The refresh token is a long-lived secret that the application uses to obtain new access tokens without re-prompting the user. For confidential clients (server-side applications), refresh tokens have a 90-day sliding window — each use extends the lifetime by another 90 days. For single-page applications, the lifetime is 24 hours. Refresh tokens are not configurable through token lifetime policies — since January 2021, Entra ID uses only the default values, and session control is managed through Conditional Access sign-in frequency instead.

An attacker who steals a refresh token can silently generate new access tokens for as long as the refresh token remains valid — potentially months for confidential client flows. Revoking the user's sessions through Revoke-MgUserSignInSession invalidates the refresh token, but the access tokens already issued from it remain valid until they expire. This revocation gap is the reason incident responders need to understand token lifetimes: the time between "sessions revoked" and "attacker loses access" depends entirely on whether CAE is enabled and whether the target application supports CAE critical event evaluation.

The ID token is a signed JWT that contains claims about the user — their name, email, tenant ID, and the authentication methods they used. Applications use ID tokens to establish the local session. The ID token itself is not used to access APIs, but it contains information an attacker can use for reconnaissance.

Understanding where these tokens live on a device matters for both incident response and prevention. On Windows devices joined to Entra ID, tokens are managed by the Web Account Manager (WAM) and the CloudAP plugin. The PRT is stored in the device's TPM-protected key store. Access and refresh tokens are cached by WAM and by individual applications — browser session cookies, Outlook's token cache, Teams' local storage. On macOS, the Microsoft Enterprise SSO plugin manages the equivalent functions. Each of these storage locations is a potential extraction point for an attacker with local access to the device.

Microsoft 365 applications also share tokens through a mechanism called Family of Client IDs (FOCI). Applications in the same family — Outlook, Teams, OneDrive, SharePoint — can use the same refresh token. This means a refresh token obtained by compromising one application can generate access tokens for every application in the family. FOCI simplifies the user experience (sign in once, access everything), but it also means that token theft from any one M365 application grants access to all of them.

{
  "token_type": "Bearer",
  "expires_in": 4799,
  "ext_expires_in": 4799,
  "access_token": "eyJ0eXAiOiJKV1Qi...[truncated]",
  "refresh_token": "0.AToAK1Nh...[truncated]",
  "id_token": "eyJ0eXAiOiJKV1Qi...[truncated]"
}

The expires_in field shows 4,799 seconds — approximately 80 minutes. This is the access token's lifetime. After this period, the application silently uses the refresh token to obtain a new access token. The user sees nothing. The refresh token itself has no expires_in field in the response — its lifetime is governed by Entra ID's backend policies, not a claim in the token itself.

The Primary Refresh Token

Beyond the three standard tokens, devices joined or registered to Entra ID maintain a Primary Refresh Token (PRT). The PRT is a device-level credential that provides single sign-on across all applications on that device. It refreshes every four hours on joined and hybrid-joined devices when the user unlocks the device or signs in interactively.

The PRT is the most valuable token an attacker can steal from a device. With a PRT, the attacker can generate access tokens for any application the user has access to — not just the one they initially compromised. PRT theft is the mechanism behind session token extraction attacks using tools like ROADtools, AADInternals, and RequestToken. The attacker extracts the PRT from the device's token broker (on Windows, this is the CloudAP plugin), then replays it from any machine to obtain access tokens.

Token protection — a Conditional Access session control covered in EI7 — binds access tokens to the device that requested them. A token bound to Device A is rejected when presented from Device B. This is the architectural defense against token theft: even if the attacker extracts the PRT, the access tokens generated from it are cryptographically bound to the original device and useless on any other. As of 2026, token protection supports Office 365 applications in public preview, with broader application support expanding through the year. Understanding which applications support token protection — and which don't — is critical for designing policies that don't create gaps.

Where attackers target the flow

Each attack pattern in this course maps to a specific point in the authentication flow.

AiTM credential phishing targets the credential exchange at step 4. The proxy captures the session token returned after MFA completion. The attacker never needs the user's password or MFA method — they need the token that MFA produces. Defense: phishing-resistant authentication methods that cryptographically verify the domain (EI2, EI4).

Token theft from the device targets step 9 and beyond — extracting access tokens, refresh tokens, or the PRT from a compromised endpoint. The attacker replays these tokens from their own machine. Defense: token protection that binds tokens to the issuing device (EI7), compliant device requirements (EI4).

OAuth consent phishing bypasses the authentication flow entirely. The attacker doesn't steal credentials or tokens — they trick the user into granting an OAuth application permission to access their data. The application then uses its own tokens to access the user's mailbox, files, and calendar. These permissions survive password resets and MFA changes because the application has its own credential. Defense: blocking user consent and restricting application permissions (EI9).

Password spray targets step 3 — brute-forcing the credential validation. The attacker tries common passwords against many accounts at low velocity to avoid lockout thresholds. Defense: phishing-resistant authentication that eliminates passwords entirely, or Conditional Access policies that block legacy authentication and require MFA (EI2, EI4).

Device code flow abuse exploits a legitimate authentication flow designed for devices without browsers — smart TVs, IoT devices, printers. The attacker sends the user a device code and convinces them to enter it at microsoft.com/devicelogin. When the user authenticates, the tokens are sent to the attacker's device, not the user's. Defense: blocking device code flow in Conditional Access (EI4) and monitoring for device code flow sign-ins in Sign-in logs (EI13).

MFA fatigue targets step 4 specifically — the attacker has the user's password (from a previous breach, spray, or purchase) and triggers repeated push notification prompts until the user approves one out of frustration or confusion. Defense: number matching in Authenticator (now default), phishing-resistant methods that don't use push notifications, and Conditional Access policies that require authentication strength rather than generic MFA (EI2, EI4).

// Which authentication methods are your users actually using?
// This tells you how exposed you are to each attack vector
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "0"
| extend AuthMethod = tostring(AuthenticationDetails[0].authenticationMethod)
| summarize SignIns = count() by AuthMethod
| sort by SignIns desc
// "Password" or "SMS" = vulnerable to AiTM and MFA fatigue
// "FIDO2 security key" or "Passkey" = phishing-resistant

This query shows the distribution of authentication methods across your successful sign-ins. If the majority show "Password" as the primary method with "Microsoft Authenticator notification" or "SMS" as the second factor, your environment is vulnerable to AiTM phishing — the attacker captures the session token after both factors complete. If you see "FIDO2 security key" or "Passkey (Microsoft Authenticator)," those sign-ins are architecturally resistant to AiTM because the authentication is cryptographically bound to the real login.microsoftonline.com domain.