In the world of modern identity and access management, tokens are the digital keys that unlock secure access to resources. Microsoft Entra ID (formerly Azure Active Directory) relies on these tokens to authenticate users, authorize applications, and enforce security policies. Whether you’re a developer building apps, an admin managing access, or a security pro auditing sessions, grasping the nuances of token types, their lifespans, and how they interplay with features like Conditional Access, MFA, and authentication strengths is crucial. This post dives deep into these elements, complete with tables, scenarios, and references to official Microsoft documentation.
We’ll cover token types and lifetimes first, then explore how Conditional Access policies influence them, the ties to MFA and authentication strengths, resource and application access patterns, and finally, who (or what) can end a token’s life—think admin revocations or even a simple laptop hibernation.
Token Types in Entra ID: The Building Blocks
Entra ID issues several token varieties, each serving a distinct role in the authentication and authorization flow. They primarily follow OAuth 2.0 and OpenID Connect standards, with JSON Web Tokens (JWTs) as the common format for portability and verifiability.
Here’s a quick comparison table of the core token types:
| Token Type | Purpose | Format | Key Claims/Features | Typical Use Case |
|---|---|---|---|---|
| Access Token | Authorizes access to protected resources (e.g., APIs) on behalf of a user. Not for proving identity. | JWT (opaque to clients) | aud (audience/resource), scp (scopes), exp (expiry), iss (issuer). Versions: v1.0 (Entra-only apps), v2.0 (consumer support). | Calling Microsoft Graph API for email access in a mobile app. |
| ID Token | Proves successful authentication and provides user identity details for the client app. | JWT | sub (subject/user ID), email, name, iat/nbf/exp (timestamps), nonce (anti-replay). | Signing into a web app and displaying user profile info. |
| Refresh Token | Requests new access/ID tokens without re-authentication. Long-lived for seamless sessions. | Opaque string | Bound to user+client combo; self-renewing. Types: Confidential (secure apps), Public (e.g., SPAs). | Background refresh of an expired access token in a desktop client. |
| Primary Refresh Token (PRT) | Device-bound token for SSO across apps on registered devices (Windows, iOS, etc.). Carries device claims for policy enforcement. | Secure artifact | Types: Registered (Entra-joined devices), Unregistered (personal devices). Includes NGCPRT (Next Gen Crypto PRT) for enhanced security. | SSO to Teams and Outlook on a compliant Windows laptop. |
Access tokens are the workhorses for resource calls—clients send them to APIs, which validate claims like audience (aud) and issuer (iss) against OpenID Connect metadata. ID tokens, meanwhile, are client-facing proofs of auth, packed with user claims but unsuitable for authorization. Refresh tokens keep sessions alive by trading themselves for fresh pairs, while PRTs supercharge device SSO, embedding compliance info for Conditional Access checks.
Scenario: Building a Multi-Tenant App
Imagine developing a SaaS tool that integrates with Microsoft 365. You request an authorization code flow, yielding an ID token for user login (verifying aud matches your app ID) and an access token scoped to Mail.Read. A refresh token handles token rotation every 90 days. For device users, a PRT enables silent SSO across tenants.
Token Lifetimes: Defaults, Configurability, and Variability
Token lifetimes balance security (short-lived = less exposure) with usability (no constant re-auth). Entra ID defaults are randomized for resilience, but you can tweak them via policies.
- Access Tokens: 60-90 minutes (avg. 75 min), variable to avoid thundering herd issues. With Conditional Access Sign-in Frequency (SIF), add the interval (e.g., 1-hour SIF + 75-min token = up to 2.5-hour sessions). Configurable: 10 min to 1 day via Token Lifetime Policies (TLPs).
- ID Tokens: Fixed 1 hour. Configurable: 10 min to 1 day, controlling app session expiry.
- Refresh Tokens: 24 hours (SPAs, due to cookie restrictions) or 90 days (others). Self-renewing; max inactive period is 90 days. Not configurable—use SIF instead.
- PRTs: 90 days, renewed every 4 hours on Windows (or on reconnect). Limited by SIF controls.
Configurable Token Lifetimes (CTL): Apply organization-wide or per-app/service principal via Microsoft Graph (e.g., New-MgPolicyTokenLifetimePolicy). Requires Entra ID P1. Can’t override for refresh/PRT; SAML tokens get 1-hour default + 5-min skew.
Table: Lifetime Impacts by Feature
| Feature/Policy | Access Token Effect | ID Token Effect | Refresh/PRT Effect |
|---|---|---|---|
| Default | 60-90 min | 1 hour | 90 days / 90 days |
| CTL Policy | 10 min-1 day | 10 min-1 day | N/A |
| SIF (1 hour) | +SIF interval (up to 2.5 hours) | N/A | Controls max session |
| CAE Enabled | Up to 28 hours (long-lived) | Unaffected | Revocation on events, not expiry |
Scenario: Enforcing Shorter Lifetimes for High-Risk Apps
For a finance app, set a TLP to 15-min access tokens. Users re-auth every 15 min, but a 90-day refresh token minimizes prompts—until SIF kicks in for weekly interactive MFA.
Conditional Access Policies: Shaping Token Behavior
Conditional Access (CA) policies dynamically evaluate signals like user risk, location, and device compliance to grant/deny access, directly influencing tokens.
- Session Lifetime Controls: Use “Sign-in frequency” to cap sessions (e.g., every 8 hours), overriding token expiry for re-eval. “Persistent browser session” extends via PRT for compliant devices.
- Token Protection: A CA session control binding refresh tokens to devices (via PRT) to thwart replay attacks. Enforced for Exchange/Teams/SharePoint; blocks unbound tokens with errors like 1002 (no device state).
- Continuous Access Evaluation (CAE): Extends access tokens to 28 hours while monitoring real-time events (e.g., account disable). Revokes via claim challenges on policy violations, integrated with CA for IP/location checks.
Scenario: CA for Remote Workers
Policy: Require compliant device + MFA for VPN access. On violation (e.g., risky IP), CAE revokes the 28-hour token instantly, forcing re-auth. Token Protection ensures only the bound device succeeds.
MFA Correlation, Authentication Strengths, and Auth Types
MFA ties deeply to tokens: Entra requires MFA satisfaction for tokens with MFA claims, embedding proofs in ID/access tokens. Authentication strengths refine this in CA, specifying method combos (e.g., password + Authenticator app).
Built-in Strengths (non-editable):
- MFA Strength: Password + any “something you have” (e.g., Authenticator push).
- Passwordless MFA: FIDO2 key or Windows Hello (no password).
- Phishing-Resistant MFA: FIDO2/CBA (multi-factor certs) for proof-of-possession.
Custom strengths allow tailoring (e.g., FIDO2 + biometrics). Evaluated post-initial auth; unsatisfied prompts registration.
Auth Types Covered:
- OAuth 2.0: For access tokens (delegated/implicit flows).
- OpenID Connect: Layers ID tokens on OAuth for auth.
- SAML: Federated tokens (1-hour default).
Scenario: Risk-Based MFA
High-risk sign-in? CA policy requires Phishing-Resistant MFA strength. User taps FIDO2 key; token issues with claims proving resistance. Without it, access denied—correlating MFA directly to token validity.
Table: MFA Methods by Strength
| Method | MFA Strength | Passwordless | Phishing-Resistant |
|---|---|---|---|
| FIDO2 Security Key | Yes | Yes | Yes |
| Windows Hello | Yes | Yes | Yes |
| Authenticator (Push) | Yes | No | No |
| SMS/OTP | Yes | No | No |
Resource and Application Access: Tokens in Action
Tokens drive access: Access tokens scope permissions (e.g., User.Read) for APIs; ID tokens bootstrap app sessions. Apps validate via metadata endpoints (e.g., /v2.0/.well-known/openid-configuration). For applications, PRTs enable SSO; refresh tokens support background access.
Sample Flow (OAuth 2.0 + OIDC):
- User auths → ID token issued (1-hour life).
- App requests access token for Graph API → Scoped to resource.
- Expiry? Refresh token swaps for new pair.
CA might interject: “Require MFA strength” → Token only if satisfied.
Scenario: API Access in a Web App
A React SPA uses MSAL.js: On login, gets ID token for UI, access token for backend proxy to Graph. CA policy blocks if from untrusted IP, revoking via CAE.
Terminating Tokens: Revocation, Actions, and Scenarios
Tokens don’t last forever—revocation ensures security. Who can terminate? Admins (via roles like Global Admin) revoke all refresh/PRTs per user (Revoke-MgUserSignInSession). Users self-revoke via portal. Apps enforce based on policies.
Actions/Scenarios:
- Admin Revoke: Instant for refresh/PRTs; access tokens expire naturally (1 hour). Impacts: New tokens blocked; sessions end on expiry.
- Password Change/SSPR: Invalidates non-password-based tokens; PRTs require re-issue.
- Account Disable/Delete: PRTs/tokens invalidated; cached sessions may linger until detection.
- Network Disconnect: PRTs cached for offline SSO (up to 90 days); no termination, but renewal waits for reconnect (every 4 hours on Windows).
- System Hibernation: No direct termination—PRT remains valid. Renewal delayed until wake + internet; if >90 days inactive, expires. TPM issues (e.g., post-hibernation failure) trigger recovery, invalidating PRT.
- CAE Event: High risk? Policy revokes mid-session via claim challenge.
Scenario: Emergency Revocation
Suspected compromise: Admin disables account + revokes sessions. User on hibernated laptop wakes to expired PRT; network reconnect fails renewal due to disable—forced re-auth reveals block.
Table: Termination Triggers
| Trigger | Affected Tokens | Time to Impact | Mitigation Example |
|---|---|---|---|
| Admin Revoke | Refresh/PRT/Session | Immediate | PowerShell: Revoke-MgUserSignInSession |
| Password Change | PRT/Non-password tokens | On next use | Re-auth with new creds |
| Network Disconnect | None (cached) | None | Offline SSO via PRT |
| Hibernation | PRT (delayed renewal) | Up to 90 days | Wake + reconnect for renewal |
In summary, Entra ID tokens are a symphony of security and convenience—tune them wisely with CA and strengths. For hands-on, check the Graph API for TLPs or test CA policies in report-only mode.
References
- Microsoft Docs on Access Tokens.
- ID Tokens.
- Refresh Tokens.
- Configurable Lifetimes.
- PRT Overview.
- CAE.
- Token Protection.
- Auth Strengths.
- Revoke Access.
- Auth Strength How-To.