In this module
EI0.2 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 in this flow.
The authentication flow in Microsoft 365 follows the OAuth 2.0 and OpenID Connect (OIDC) standards. These are not Microsoft-specific — they are industry standards used by every major cloud provider. Microsoft's implementation adds layers of risk evaluation, conditional access policy enforcement, and token binding that are specific to Entra ID, but the underlying flow is standard.
The tokens: what they are and why attackers want them
The three tokens returned by Entra ID serve different purposes, have different lifetimes, and represent different levels of risk if stolen.
The access token is the credential that applications present to resource APIs (such as the Microsoft Graph API or the Exchange Online API) to prove the user is authorized. Access tokens are short-lived — typically 60 to 90 minutes by default, though some resources use shorter durations. An access token contains the user's identity, the permissions granted, the audience (which API the token is valid for), and the expiration time. When an access token expires, the application must obtain a new one. Because access tokens are short-lived, stealing a single access token gives the attacker a narrow window of access. However, during that window, the attacker has exactly the permissions the token contains.
Where tokens live on the device
Understanding where tokens are stored is essential for both defense (protecting the storage locations) and investigation (knowing where to look for evidence of token theft).
On Windows devices, the PRT is stored in the Cloud AP plugin and protected by the Trusted Platform Module (TPM) when Credential Guard is enabled. Without Credential Guard, the PRT key material is accessible in the LSASS process memory — which is exactly where tools like Mimikatz extract it. Refresh tokens for native applications are managed by the Web Account Manager (WAM) broker and stored in the token cache. Browser-based session tokens (cookies) are stored in the browser's cookie store — for Edge and Chrome, this is a SQLite database in the user's profile directory that malware frequently targets for cookie theft.
Family of Client IDs (FOCI) and token sharing
An important nuance that many administrators miss: Microsoft applications share tokens through a mechanism called Family of Client IDs (FOCI). When a user authenticates to one Microsoft application (such as Outlook), the resulting refresh token can be exchanged for access tokens to other Microsoft applications in the same family (such as Teams, OneDrive, or SharePoint) — without requiring the user to authenticate again, and without triggering a new sign-in log entry for each application.
From a security perspective, FOCI means that stealing a single refresh token issued to any Microsoft first-party application grants the attacker access to every Microsoft first-party application in the family. The sign-in logs will show the original authentication event but may not show the attacker's subsequent access to other applications obtained through FOCI token exchange. This is why refresh token theft is so dangerous — and why token protection (which binds the refresh token to the device) is a critical defense.
From an investigation perspective, FOCI explains why an attacker can access SharePoint, OneDrive, and Teams without generating separate sign-in events for each. The IR course (specifically IR8 and IR11) covers how to detect this pattern. This course teaches you to deploy token protection and sign-in frequency controls that mitigate it.
The myth: A user was compromised. We reset their password. The attacker is locked out.
The reality: A password reset invalidates the user's password-based credentials but does not automatically revoke all existing tokens. If the attacker stole a refresh token before the password reset, that refresh token may remain valid depending on the token revocation configuration. If the attacker registered a rogue OAuth application with its own credentials, those application credentials survive the user's password change entirely. Effective remediation requires revoking all sessions (which invalidates refresh tokens and the PRT), resetting the password, reviewing and removing any unauthorized OAuth application consent grants, and reviewing any conditional access or directory changes the attacker may have made during the compromise. EI7 covers token security in depth, and the IR course covers the full remediation workflow.
Where attackers strike in the authentication flow
Understanding the flow reveals the attack surface. Every identity attack in this course targets a specific point:
At the credential step (steps 3-4): Password spray attacks attempt to guess passwords. AiTM phishing attacks present a fake sign-in page that proxies the real Entra ID login, capturing both the user's credentials and the resulting session token after MFA completion. MFA fatigue attacks flood the user with push notifications until they approve one. Each of these attacks targets the moment the user proves their identity — and each is defeated by a different defense that this course teaches you to deploy.
// EI0.2 — What authentication methods are your users using?
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0 and AuthenticationRequirement == "multiFactorAuthentication"
| extend Method = tostring(parse_json(tostring(MfaDetail)).authMethod)
| where isnotempty(Method)
| summarize Users = dcount(UserPrincipalName) by Method
| order by Users desc
// Shows your current MFA method distribution
// Are users on phishing-resistant methods or still on SMS/phone?Try it yourself
Try It — Trace Your Own Authentication Flow
Environment: Your M365 developer tenant.
Exercise: Open an InPrivate/Incognito browser window and sign in to portal.office.com with a test user from your developer tenant. While signing in, pay attention to each step:
1. What happened when you entered the email address? (Tenant identification) 2. What authentication challenge were you presented? (Password? Authenticator?) 3. Were you prompted for a second factor? (MFA requirement) 4. Did you see any consent prompts? (Application permissions)
Now open the Entra admin center → Identity → Monitoring & health → Sign-in logs. Find the sign-in you just performed. Look at the Authentication Details tab — it shows exactly which steps occurred and in which order. Look at the Conditional Access tab — it shows which policies evaluated and what they decided.
This is the telemetry that every module in this course teaches you to use for verification and monitoring.
You are reviewing NE's Entra ID security posture. You find 4 accounts with Global Administrator role, but NE's policy says maximum 2. The extra 2 were added during the AiTM incident for emergency response and never removed. Do you remove them?
Remove them — but through the proper process, not unilaterally. Notify the account owners that their emergency GA assignment is being revoked, confirm they have their standard role assignments restored, and document the removal with the rationale ('emergency assignment during INC-NE-2026-0227-001, no longer required'). Then add a PIR action item: 'Implement PIM time-limited role assignments for future incident response — emergency GA assignments auto-expire after 8 hours rather than persisting indefinitely.' The stale emergency assignment is a governance failure, not a technical failure — the fix is procedural.
You've mapped the identity threat landscape and learned to read sign-in logs.
EI0 established that every cloud attack starts with identity. EI1 took you through the signal that matters most — interactive, non-interactive, service principal, and managed identity sign-ins. Now you engineer the defences.
- 17 engineering modules — authentication methods, conditional access architecture, Identity Protection, PIM, token protection, application governance, and detection rules
- The Defense Design Method — the six-step framework applied to every identity control you'll build
- EI18 Capstone — Identity Security Architecture Design — design complete identity architectures for three realistic organisations (SMB, mid-market, regulated enterprise)
- Identity Security Toolkit lab pack — deployable conditional access policies, PIM configurations, and Identity Protection risk rules
- Cross-domain detection (EI16) — email-to-identity correlation and the full phishing-to-inbox-rule attack chain