How Authentication Actually Works

Introduction

Everything an attacker does after a successful sign-in happens with a token, so a course about identity has to start by being precise about what a token is. You will finish able to say which token was stolen from an alert, what it authorizes, and whether revoking sessions actually invalidates it.

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.

Consent is the one route on that list that never touches a password.

  1  App redirects       AiTM proxy at the redirect
  2  Sign-in page shown   an identical-looking page
  3  User proves identity password spray, MFA fatigue
  4  CA evaluates         nothing: bypassed by not matching
  5  Tokens issued        theft and replay

Two of those rows carry the section. Step 1 is attacked because the application never handles the credential. It redirects, which is the entire point of the standard and the reason a convincing redirect is an attack rather than an implementation bug.

Step 3 is the only step a phishing-resistant method actually changes. Everything else in the sequence is unaffected by which factor the user presents, which is why the choice of method is a narrower decision than it is usually treated as, and a more consequential one.

Step 4 is worth reading carefully because it is not attacked at all. Conditional Access is bypassed by a sign-in not matching a policy, per ei03, and that is a gap in scope rather than an attack on the control. Nothing has to defeat it.

Now read step 5 against the four above it. Four steps decide whether to issue, and the fifth produces a bearer credential that carries the decision away with it. Every control in rows 1 to 4 has already passed by the time the token exists, which is the fact every later module is answering.

The asymmetry in that last line decides where a defense can act at all. Four steps evaluate and the fifth hands over something that no longer needs evaluating, so a stolen token is a completed authentication rather than an attempt at one, and every control from steps 1 to 4 has already said yes.

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 24 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.

Two further limits on that call are worth knowing before you rely on it in an incident. Microsoft's own documentation notes a delay of a few minutes between the call returning and tokens actually being revoked, so a responder who revokes and immediately checks has not proven anything. And the call does not revoke sessions for external users, because a guest authenticates through their home tenant and it is that tenant's signInSessionsValidFromDateTime that governs their tokens rather than yours. Containing a compromised guest is a conversation with another organization, not a command you run.

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.

Revocation is the control that assumes you already know a token was taken.

"Bearer" means the token is presented and honored, and that is the whole problem. It carries no proof that the presenter is the person it was issued to, so a copied token is as good as the original. That is not a flaw in the design; it is the design, and it is why theft is worth more to an attacker than a password is.

Which changes what your sign-in evidence means. The authentication succeeded, honestly, with real MFA, for the real user. The theft happens after the event your logs are proud of, and no amount of scrutiny applied to that event will show it.

  WHICH TOKEN?          access expires in ~an hour
                        refresh lasts far longer
  WHAT DOES IT REACH?   the scope it was issued for
  DOES REVOCATION KILL  differs by token type

The third is the one that catches people out. Per 10.6's endpoint equivalent, a password reset does not end an established session: revocation is a separate act, and its effect differs by token type, which is why the scenario at the top of this section cannot be answered without all three questions. Every attack later in the course is answered with those three questions, so they are worth knowing before meeting the first one.

The second block is what makes token theft hard to detect with the tools most estates trust. The sign-in event is genuine and the compromise happens after it, so an audit trail full of successful, MFA-satisfied authentications is exactly what a stolen session looks like.

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 rather than 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.

  ID TOKEN         who the user is
                   stolen: a statement, not a key
  ACCESS TOKEN     may call this API
                   stolen: one app, until expiry
  REFRESH TOKEN    issue more access tokens
                   stolen: one app, until revocation
  PRIMARY REFRESH  this DEVICE has a signed-in user
  TOKEN            stolen: EVERY app the user reaches

The first three escalate in the way you would expect: a statement, then a key to one door, then the ability to keep making keys to that door.

The fourth breaks the pattern, and it is the row to remember. A primary refresh token is refreshed every four hours on joined and hybrid-joined devices and represents the device having a signed-in user, so stealing it yields not the application that was compromised but every application that user can reach.

Which is why device compromise and identity compromise are the same incident in this estate. A PRT converts one endpoint into the user's whole session, and an incident response that treats the endpoint and the identity as two workstreams will close one of them too early.

The bottom line is the join between this course and the endpoint one. A PRT is a device-level credential that grants application-level access, so an attacker who reaches the token broker on one machine holds what the user holds everywhere, which is why ARC402's endpoint work and this course's identity work meet at the same incident.

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 (ARC406).

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.

Read that list downward rather than as five separate risks. Each row is further from the password and harder for a password-shaped control to see.

The first is the 97 per cent from 0.1 and the part already answered. The second is where fatigue and push bombing live, and the method decides the outcome: a number match or a passkey is a different proposition from a yes button. The third is AiTM, and it explains why a proxy in front of a real sign-in page works: the code is intercepted in transit and the attacker completes the exchange.

The fourth needs no further authentication at all, for as long as the token lives.

The fifth is outside the sequence entirely. Consent produces a token the user granted to an application: there is no credential to steal and nothing to revoke by resetting a password. Every control that thinks in terms of credentials is looking at the wrong object.

The direction of that list is the course's argument in one artifact. Every step down it moves further from the credential and closer to the session, which is why controls designed around passwords stop helping partway down and Conditional Access has to carry the rest.

The alert in the scenario is answerable, and the exercise is being able to answer it before one arrives.

Everything after a successful sign-in happens with a token, and a token is a bearer credential: it is presented and honoured, and it carries no proof that the presenter is the person it was issued to. A copied token is as good as the original, which is the design rather than a flaw in it, and it is why theft is worth more than a password. That also changes what your evidence means, because the sign-in was genuine and MFA really was satisfied, so a stolen session looks like a clean authentication trail. An alert therefore asks three things: which token, what it reaches, and whether revocation ends it. And reading the attack surface downward from the password to consent shows each step moving further from the credential, which is where password-shaped controls stop helping.