This chapter covers token lifetime and session control policies in Microsoft Entra ID (formerly Azure AD), a critical topic for the AZ-104 exam under Identity Governance (Objective 1.1). Understanding how tokens are issued, refreshed, and revoked is essential for managing authentication security and user experience. Approximately 10-15% of exam questions in domain 1 touch on token management, session policies, or authentication session controls. You will learn the exact default values, configuration methods, and how Conditional Access policies override default lifetimes.
Jump to a section
Think of token lifetime and session control policies like a hotel's key card system. When you check in (authenticate), the front desk issues a key card (token) that grants access to your room and amenities (resources). The card has a printed expiration date (token lifetime) — say 7 days. However, the hotel also has a policy that if you don't use your card to enter your room or the gym for 24 hours (session idle timeout), the card deactivates. Additionally, the hotel offers a 'frequent guest' program where, if you stay more than 3 times a year, your key card automatically renews each morning (refresh token) without visiting the front desk. But there's a catch: if you change rooms (resource access change), the old card stops working immediately. The front desk maintains a log of all card activations and usage (session metadata). If a guest tries to use an expired card, the door lock rejects it, and the guest must return to the front desk to authenticate again. This mirrors how Microsoft Entra ID issues access tokens (key cards) with a default lifetime of 60-90 minutes, refresh tokens (automatic renewals) that last up to 90 days with inactivity, and session tokens that are tied to the user's sign-in session. Conditional Access policies act like hotel rules that can shorten these lifetimes based on risk, location, or device compliance. The front desk's log is like the sign-in logs in Azure AD, which administrators review to detect unusual activity.
What Are Token Lifetime and Session Control Policies?
Token lifetime and session control policies define how long authentication tokens remain valid after a user signs in. Tokens are the fundamental mechanism by which applications and services verify a user's identity without requiring repeated credentials. Microsoft Entra ID issues three primary token types: - Access tokens: Used by client applications to access APIs. Default lifetime: 60-90 minutes (varies by client). - Refresh tokens: Used to obtain new access tokens without re-authentication. Default lifetime: 90 days (if inactive for 90 days, it expires). - Session tokens (ID tokens): Represent the user's sign-in session. Default lifetime: until the browser is closed or sign-out occurs.
Session control policies, configured via Conditional Access, allow administrators to enforce sign-in frequency and persistent browser session limits. These policies override default token lifetimes and are applied at authentication time.
Why They Exist
Without token lifecycle management, tokens would be valid indefinitely, creating security risks. If a token is stolen, an attacker could impersonate the user indefinitely. By setting finite lifetimes and requiring periodic re-authentication, organizations reduce the window of opportunity for token theft. Session control policies also help meet compliance requirements (e.g., requiring re-authentication every hour for sensitive apps).
How Tokens Work Internally
When a user signs in via OAuth 2.0 or OpenID Connect, the authentication flow proceeds as follows:
The user authenticates to the Microsoft Entra ID authorization endpoint.
Entra ID issues an ID token (session token) and an access token to the client application.
The client uses the access token to call an API (e.g., Microsoft Graph).
When the access token expires (default 60-90 minutes), the client uses the refresh token to request a new access token without prompting the user.
The refresh token itself has a lifetime (default 90 days of inactivity). If the user does not use the application for 90 days, the refresh token expires, and the user must re-authenticate.
Session tokens are stored in browser cookies (for web apps) or in the client's secure storage. The session token's lifetime is tied to the browser session: it ends when the user closes the browser or explicitly signs out.
Key Components, Defaults, and Timers
Access Token Lifetime: Default 60 minutes for most Microsoft services, 90 minutes for some third-party apps. Configurable via token lifetime policies (preview feature) in the Azure portal or PowerShell.
Refresh Token Lifetime: Default 90 days of inactivity. Sliding window: each time a refresh token is used, the 90-day clock resets. Maximum lifetime: until revoked or user changes password.
Session Token Lifetime: Default until browser close (non-persistent). For persistent sessions, can be configured via Conditional Access "Persistent browser session" control.
Sign-in Frequency: Configured via Conditional Access policy. Forces re-authentication after a specified time (e.g., every 1 hour). Overrides default token lifetimes.
Token Revocation: Occurs when:
User changes password.
Admin revokes sessions via Azure portal or PowerShell.
User is disabled or deleted.
Token lifetime expires.
Configuration Methods
Token lifetime policies can be configured via:
1. Azure Portal: Azure Active Directory > App registrations > (select app) > Token configuration > Add optional claim (not lifetime). For lifetime, use PowerShell or Conditional Access.
2. PowerShell: Use New-AzureADPolicy to create a token lifetime policy and assign to an application or service principal.
3. Conditional Access: Under Access controls > Session > Sign-in frequency or Persistent browser session.
Example PowerShell to create a token lifetime policy:
$policy = New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"01:00:00","MaxAgeSessionSingleFactor":"08:00:00","MaxAgeSessionMultiFactor":"08:00:00"}}') -DisplayName "MyTokenLifetimePolicy" -Type "TokenLifetimePolicy"
Add-AzureADApplicationPolicy -Id $applicationObjectId -RefObjectId $policy.IdInteraction with Conditional Access
Conditional Access policies can override default token lifetimes by specifying: - Sign-in frequency: Forces user to re-authenticate after a specified period (e.g., 1 hour). This effectively shortens access token lifetime because the user must re-authenticate to get a new session. - Persistent browser session: Controls whether the session cookie persists after browser close. If disabled, the user must sign in each time they open the browser.
These controls are applied at authentication time and are independent of token lifetime policies. If both are configured, the more restrictive setting applies.
Verification Commands
To verify token lifetime settings:
- Azure AD Sign-in Logs: Check "Authentication requirement" column to see if token lifetime policy was applied.
- PowerShell: Get-AzureADPolicy to list policies, Get-AzureADApplicationPolicy to see assignments.
- Microsoft Graph: Query /policies/tokenLifetimePolicies.
Common Scenarios
High-security apps: Set sign-in frequency to 15 minutes via Conditional Access.
Long-running background services: Increase access token lifetime to 24 hours (but refresh tokens are preferred).
Kiosk devices: Use persistent browser session to avoid repeated sign-ins.
Edge Cases
Refresh token sliding window: If a user uses an app every 89 days, the refresh token never expires. But if they stop using it, after 90 days it expires.
Token lifetime policies are in preview: Microsoft recommends using Conditional Access for session control instead of token lifetime policies, as the latter may be deprecated.
First-party vs third-party apps: Some Microsoft apps have their own token lifetime settings that may override defaults.
User Authenticates via OAuth 2.0
The user navigates to an application (e.g., a web app) that requires authentication. The app redirects the user to Microsoft Entra ID's /authorize endpoint. The user provides credentials (username/password, MFA, etc.). Entra ID validates the credentials and generates an authorization code, which is sent back to the app. This step establishes the user's identity and initiates the token issuance process. The authorization code is short-lived (typically 10 minutes) and must be exchanged for tokens immediately.
Tokens Are Issued to the Client
The application exchanges the authorization code for an access token, a refresh token, and an ID token at the /token endpoint. The access token is a JWT (JSON Web Token) containing claims such as 'aud' (audience), 'iss' (issuer), 'exp' (expiration time), and 'sub' (subject). The default expiration time (exp) is set to 60-90 minutes from issuance. The refresh token is opaque and has a default lifetime of 90 days of inactivity. The ID token contains user profile claims and is used for session management. The client stores these tokens securely.
Client Uses Access Token to Call API
The client application includes the access token in the Authorization header (as a Bearer token) when calling a protected API, such as Microsoft Graph. The API validates the token by checking its signature, expiration time, and audience. If valid, the API processes the request and returns data. The access token is typically cached by the client until it expires. During this period, the user can access resources without re-authentication.
Access Token Expires; Refresh Token Used
When the access token expires (after 60-90 minutes), the client attempts to use the refresh token to obtain a new access token. It sends a request to the /token endpoint with the refresh token and client credentials. Microsoft Entra ID validates the refresh token: if it is still valid (i.e., not expired and not revoked), it issues a new access token (with a new expiration) and optionally a new refresh token. This process is transparent to the user. The refresh token's idle timer resets each time it is used.
Refresh Token Expires or Session Ends
If the user does not use the application for 90 consecutive days, the refresh token expires. The client then cannot obtain a new access token without user interaction. The user must re-authenticate to get a new refresh token. Additionally, the session token may expire if the user closes the browser (non-persistent session) or if a Conditional Access policy enforces sign-in frequency. When the session ends, all tokens associated with that session are invalidated.
Enterprise Scenario 1: Financial Services App with Strict Compliance
A bank deploys a customer-facing web application that allows users to view account balances and transfer funds. Compliance regulations require that users re-authenticate every 15 minutes for sensitive operations. The administrator configures a Conditional Access policy targeting the app with "Sign-in frequency" set to 15 minutes. This policy overrides the default 60-minute access token lifetime. Users must enter their password (and possibly MFA) every 15 minutes, even if they are actively using the app. This ensures that if a user walks away from their device, an attacker has only a 15-minute window to misuse the session. The bank also enables persistent browser session to allow users to stay signed in across browser restarts, but the 15-minute re-authentication still applies. The challenge is user experience: high-frequency re-authentication leads to complaints. The bank mitigates by using MFA with biometrics for faster re-authentication.
Enterprise Scenario 2: SaaS Application with Long-Running Background Jobs
A SaaS provider offers a service that runs background jobs (e.g., data processing) on behalf of users. The jobs may run for several hours and require continuous access to Microsoft Graph. The default access token lifetime (60 minutes) would cause jobs to fail if the token expires. The administrator uses token lifetime policies (via PowerShell) to increase the access token lifetime for the service principal to 24 hours. However, they also implement a secure token cache that automatically refreshes tokens before expiration using the refresh token. They set the refresh token lifetime to 180 days (via policy) because jobs may not run daily. This avoids job failures due to token expiry. The administrator monitors Azure AD sign-in logs to ensure no unusual activity occurs with the long-lived tokens.
Enterprise Scenario 3: High-Security Remote Access with Conditional Access
A government agency allows employees to access internal applications from remote locations. They require strong session control: users must re-authenticate every hour, and sessions cannot persist across browser restarts. They configure a Conditional Access policy targeting all cloud apps with "Sign-in frequency" = 1 hour and "Persistent browser session" = Never. Additionally, they use sign-in risk policies to require MFA when sign-in risk is medium or higher. The administrator must balance security with usability: employees working on sensitive documents are interrupted every hour. The agency trains users to expect this and provides a secure token storage solution (e.g., Windows Hello for Business) to speed up re-authentication. Misconfiguration example: if the administrator sets sign-in frequency to 1 hour but also configures a token lifetime policy with access token lifetime of 8 hours, the Conditional Access policy takes precedence, and users still re-authenticate every hour. This can confuse administrators who think the token lifetime policy would extend the session.
What AZ-104 Tests on Token Lifetime and Session Control
The AZ-104 exam tests your ability to configure and manage authentication sessions using Conditional Access and token lifetime policies. Specific objectives include: - 1.1 Manage identities in Microsoft Entra ID: Configure token lifetime policies, session control policies, and understand default token lifetimes. - 1.2 Manage authentication: Implement Conditional Access policies with session controls (sign-in frequency, persistent browser session). - 1.3 Manage access reviews: Not directly, but token expiration ties into access reviews.
Common Wrong Answers and Why Candidates Choose Them
"Token lifetime policies are the recommended way to control session duration." – WRONG. Microsoft recommends using Conditional Access session controls (sign-in frequency and persistent browser session) because token lifetime policies are in preview and may be deprecated. Candidates choose this because they see token lifetime policies in the portal.
"Setting a sign-in frequency policy does not affect access token lifetime." – WRONG. Sign-in frequency forces re-authentication, which effectively shortens the access token lifetime because a new token is issued after re-authentication. Candidates think tokens have fixed lifetimes independent of policies.
"Refresh tokens never expire if used regularly." – PARTIALLY WRONG. Refresh tokens have a maximum lifetime (default 90 days) even with regular use, but the sliding window resets on each use. However, the token can still be revoked. Candidates assume indefinite validity.
"Persistent browser session means the user never has to sign in again." – WRONG. Persistent browser session only keeps the session cookie after browser close, but sign-in frequency can still force re-authentication. Candidates confuse persistence with token lifetime.
Specific Numbers and Terms to Memorize
Default access token lifetime: 60-90 minutes.
Default refresh token lifetime: 90 days (inactivity).
Token lifetime policies: Use PowerShell New-AzureADPolicy with -Type "TokenLifetimePolicy".
Conditional Access session controls: "Sign-in frequency" (in hours or days), "Persistent browser session" (Always, Never).
Sign-in frequency can be set as low as 1 hour.
Edge Cases and Exceptions
First-party Microsoft apps (e.g., Office 365) may have their own token lifetimes that override defaults. For example, SharePoint Online has a session timeout setting.
Guest users: Token lifetime policies apply to guest users as well, but Conditional Access policies may require targeting external users.
Managed vs. unmanaged devices: Persistent browser session is only effective on managed devices (compliant or hybrid joined). On unmanaged devices, the setting may be ignored.
Token lifetime policy vs. Conditional Access: If both are configured, Conditional Access takes precedence for session control. Token lifetime policies still affect access token lifetime but are overridden by sign-in frequency.
How to Eliminate Wrong Answers
Look for keywords: "recommended" points to Conditional Access, not token lifetime policies.
If the question mentions "re-authenticate every hour," the answer involves Conditional Access sign-in frequency, not token lifetime.
If the question asks about "persistent browser session," it is about session cookie persistence, not token lifetime.
Remember that token lifetime policies are in preview and not recommended for production use.
Default access token lifetime is 60-90 minutes; default refresh token lifetime is 90 days of inactivity.
Use Conditional Access session controls (sign-in frequency, persistent browser session) instead of token lifetime policies for session management.
Sign-in frequency forces re-authentication at specified intervals, effectively shortening token lifetime.
Persistent browser session controls whether the session cookie survives browser close, but does not prevent sign-in frequency re-authentication.
Token lifetime policies are in preview and require PowerShell to configure; they are assigned to applications or service principals.
Refresh tokens use a sliding window: each use resets the 90-day inactivity timer.
Token revocation occurs on password change, admin revoke, user disable/delete, or token expiry.
Conditional Access session controls take precedence over token lifetime policies when both are configured.
These come up on the exam all the time. Here's how to tell them apart.
Conditional Access Session Controls
Configured via Azure portal under Conditional Access > Session.
Controls sign-in frequency and persistent browser session.
Recommended by Microsoft for session control.
Applies at authentication time and overrides token lifetimes.
Supports granular targeting (users, groups, apps, conditions).
Token Lifetime Policies
Configured via PowerShell or Microsoft Graph (preview).
Controls access token, refresh token, and session token lifetimes.
Not recommended; may be deprecated in future.
Applies to specific applications or service principals.
Less granular; cannot include conditions like location or risk.
Mistake
Token lifetime policies are the primary way to control session duration.
Correct
Microsoft recommends using Conditional Access session controls (sign-in frequency and persistent browser session) because token lifetime policies are in preview and may be deprecated. Conditional Access provides more granular and secure control.
Mistake
Setting sign-in frequency does not affect access token lifetime.
Correct
Sign-in frequency forces re-authentication, which issues a new access token. The previous token's lifetime is effectively shortened because it is no longer valid after re-authentication. The new token's lifetime is still the default 60-90 minutes, but the user must re-authenticate sooner.
Mistake
Refresh tokens never expire if the user uses the app regularly.
Correct
Refresh tokens have a maximum lifetime (default 90 days) even with regular use. The sliding window resets on each use, but the token can still expire after 90 days of inactivity. Additionally, refresh tokens can be revoked by admin actions or password changes.
Mistake
Persistent browser session means the user never has to sign in again.
Correct
Persistent browser session only keeps the session cookie after the browser is closed. However, Conditional Access sign-in frequency can still force re-authentication at intervals, and token lifetimes still apply. The user may need to sign in again if the session token expires.
Mistake
Token lifetime policies apply to all users and apps by default.
Correct
Token lifetime policies must be explicitly created and assigned to specific applications or service principals. They do not apply globally. Default lifetimes are used unless a policy is assigned.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The default access token lifetime is 60 minutes for most Microsoft services and 90 minutes for some third-party applications. This can be overridden by token lifetime policies (preview) or Conditional Access sign-in frequency. The exact default varies by client type and resource. For example, Microsoft Graph access tokens default to 60 minutes.
Sign-in frequency forces the user to re-authenticate after a specified period (e.g., 1 hour). This invalidates the current session and tokens, and a new access token and refresh token are issued. Effectively, the access token lifetime is limited to the sign-in frequency interval, even if the token itself has a longer default lifetime. The user must provide credentials again.
Yes, using token lifetime policies (preview). You create a policy with specific lifetimes and assign it to one or more applications or service principals via PowerShell. However, Microsoft recommends using Conditional Access session controls instead, which can target specific applications and conditions more granularly.
When a refresh token expires (after 90 days of inactivity), the client cannot obtain a new access token without user interaction. The next time the user tries to access the application, they will be prompted to sign in again. This triggers a new authentication flow and issuance of a new refresh token.
No. Persistent browser session only preserves the session cookie when the browser is closed, so the user does not have to sign in again on the same device after restarting the browser. However, Conditional Access sign-in frequency can still force re-authentication at intervals, and token expiration can also require re-authentication. It is not indefinite.
You can revoke all tokens by resetting the user's password (this invalidates all sessions and tokens) or by using the Azure portal: Azure Active Directory > Users > (select user) > Revoke sessions. This forces the user to sign in again on all devices and applications. PowerShell cmdlet: `Revoke-AzureADUserAllRefreshToken`.
No. Microsoft has stated that token lifetime policies are in preview and may be deprecated. The recommended approach for session control is to use Conditional Access policies with sign-in frequency and persistent browser session controls. These provide more flexibility and security.
You've just covered Token Lifetime and Session Control Policies — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?