How Entra handles token lifetimes

Arun Kumar

9 hours ago

and why “expiry time” is the wrong mental model…

If you’ve ever tried to “set Entra token lifetime to 8 hours” and walked away confused, you’re not alone. Microsoft Entra ID (formerly Azure AD) absolutely issues tokens with expiry timestamps. But in real-world Entra, “how long a user stays signed in” is governed by a stack of mechanisms: OAuth token lifetimes, refresh token rotation, browser cookies, conditional access session controls, continuous access evaluation, and explicit revocation events.

That stack is why two admins can both be “right” and still disagree. One is looking at the exp claim in an access token. The other is looking at when the user is forced to reauthenticate in a browser. Those are related, but not identical.

This article takes a first-principles approach: what Entra is optimizing for, the primitives it uses, the policy knobs that actually work in 2026, and the gotchas practitioners keep running into in production.

How Entra handles token lifetimes: Entra issues short-lived access tokens and longer-lived refresh tokens. Access tokens expire quickly (often around one hour), while refresh tokens can continuously renew access—until a user is forced to reauthenticate by conditional access session controls, risk changes, revocation events, or refresh token expiry rules. In modern Entra, “session lifetime” is mainly controlled through Conditional Access and Continuous Access Evaluation, not by simply extending access token expiry.

That’s the surface view. It’s also incomplete.

Why the surface view is incomplete

At first glance, OAuth makes it look simple:

Access token: short-lived bearer token used to call APIs.
Refresh token: long-lived secret used to get new access tokens.
ID token: authentication artifact for the client.

So you’d expect: “increase access token lifetime → users stay signed in longer.”

In Entra, that expectation breaks because:

Access tokens are not the session. They’re a cached authorization artifact used between the client and a resource. Entra deliberately keeps them short-lived to reduce blast radius.
Refresh tokens rotate and are governed by risk and policy. They “replace themselves” on each use, and policy changes can force reauthentication.
Browser sessions aren’t governed by token lifetime policies. Web “stay signed in” behavior is dominated by cookies + conditional access session controls (sign-in frequency, persistent browser session).
Continuous access evaluation can override expiry thinking. CAE lets services reject tokens before their exp, and in some cases allows longer token validity while still revoking near real-time.

So the real question isn’t “what is the token lifetime?” It’s:

“Under what conditions will Entra stop letting this client continue to mint usable access tokens without the user proving identity again?”

That’s the operational definition of “session lifetime” in Entra.

What Entra is trying to accomplish

A cloud identity provider sits between three parties:

User (human intent + authentication factors)
Client (app/device that wants ongoing access)
Resource (Exchange, SharePoint, Graph, your API)

From first principles, Entra wants:

Fast authorization checks at resource time (no network call per request).
Short blast radius if a token is stolen.
A way to adapt when risk changes after issuance (device posture flips, user disabled, location changes).
A way to force reauthentication when the organization decides the trust context is stale.

Those goals create a design bias:

Access tokens stay short.
“Session” becomes a controlled ability to refresh.
Enforcement shifts to conditional access + CAE.

That’s why Entra token lifetime is best modeled as a renewal system, not a countdown timer.

The real components of “token lifetime” in Entra

1) Access token lifetime (the easy part)

Access tokens are short-lived by design. Many Entra-issued access tokens are roughly one hour by default (varies by scenario and client/resource), and you should plan around frequent renewal.

2) Refresh tokens (the “session engine”)

Refresh tokens last longer and are used to mint new access tokens. Entra’s current documentation describes defaults like:

24 hours for single-page apps
24 hours for email one-time passcode flow
90 days for most other scenarios

But the deeper behavior is more important than the number:

Refresh tokens replace themselves each time they’re used (rotation).
Admin actions can invalidate them (revocation).

So a “90-day refresh token” does not mean “user will be prompted every 90 days.” It means: absent other controls, the refresh capability can persist up to that boundary—often longer in practice due to rotation—until invalidated or forced to reauth.

3) Browser cookies and “stay signed in”

Browser SSO depends heavily on cookies. Microsoft explicitly recommends controlling this with Conditional Access session controls like sign-in frequency and persistent browser session.

This is exactly where practitioners get tripped up, because:

“Persistent browser session” keeps sessions across browser restarts.
“Sign-in frequency” forces periodic reauthentication.
These don’t map 1:1 to access token expiry, and forum threads show ongoing confusion about how they interact.

4) Continuous access evaluation (CAE)

CAE is Entra’s “expiry is not enough” answer. In CAE-enabled services/APIs:

Resources can reject tokens before exp when critical events occur.
Tokens may be accepted longer (up to ~28 hours in some cases) while still being revocable near real time.

This is an inversion of the classic mental model. Entra is effectively saying:

“We’ll sometimes allow longer token validity, because we can revoke it smarter.”

How to configure Entra token lifetime behavior

This section is intentionally dense. It’s the part you refer back to during incidents, audits, and “why are users still signed in?” escalations.

Step 1: Identify which “session” you are actually observing

When someone says “token lifetime,” ask which symptom they mean:

API calls fail after ~60 minutes
That’s access token renewal failing (MSAL/cache/network/conditional access claims challenge).
Browser stays signed in for days
That’s cookie persistence + sign-in frequency + SSO state, not “access token lifetime.”
Office desktop apps stay signed in even when browser doesn’t
That’s often device-bound SSO artifacts and refresh behavior, not the same session control surface as browsers.
User disabled but still accessing mail for a while
That’s exactly why CAE exists; not every resource historically enforced revocation immediately without CAE.

Write down the symptom first. Then map it to the enforcement layer.

Step 2: Inspect tokens the right way (don’t guess)

For JWT access tokens, decode and check:

exp (expiry)
iat (issued at)
scp/roles (permissions)
tid, aud, iss

If your client is using MSAL, log:

token acquisition result (expiresOn)
whether it was acquired silently vs interactive
error codes (especially conditional access claims challenges)

A recurring production pattern: people “extend token lifetime” to fix an app, when the real issue is that silent renewal fails and the app never handles the interactive fallback properly.

Step 3: Understand which knobs still work in modern Entra

A. Token lifetime policies (limited scope; don’t over-invest)

Microsoft still documents configurable token lifetimes, but with important constraints and historical deprecations.

Token lifetime policies don’t apply to web browser sessions; those are managed by conditional access session controls.
Refresh/session token lifetime configuration via this older feature was retired for many scenarios and replaced by conditional access session management.

What this means in practice:

If your goal is “users must reauthenticate every X hours/days,” start in Conditional Access, not token lifetime policy.
If your goal is “a headless script needs more than 60 minutes,” first check whether your client library already renews tokens (many do). Microsoft even notes that many libraries extend as needed and you often don’t need access token policy changes.

B. Conditional access session controls (the real “session lifetime” controls)

Two controls dominate most designs:

Sign-in frequency (periodic reauthentication)
Persistent browser session (whether the browser session persists across restarts)

Key operational behavior:

Sign-in frequency forces reauthentication at the next token acquisition that requires it. It may not instantly kick a user out mid-token.
Persistent browser session changes whether closing the browser effectively ends the user’s SSO cookie state.
Community discussions highlight confusion, especially when trying to enforce different experiences for “web vs desktop apps,” because targeting is often at the resource/app level (e.g., Exchange Online) and can affect both surfaces.

Design tip: treat sign-in frequency as “maximum trust age.” Treat persistent browser session as “can trust survive a restart?”

C. Explicit revocation (what admins expect to be instant, but isn’t always)

If a device is stolen, you want to invalidate refresh ability. In Entra, you can revoke sign-in sessions, which:

invalidates refresh tokens issued to apps for a user
resets signInSessionsValidFromDateTime
may take a few minutes to fully take effect

This is where reality matters: users may continue until their current access token expires, unless the resource participates in CAE.

D. Continuous access evaluation (the modern “kick them out” mechanism)

CAE has two major enforcement paths:

Critical event evaluation (user disabled, password reset) enforced near real time in participating services.
Conditional access policy evaluation triggered by changes like location and policy requirements.

For developers, CAE changes how you build clients:

You must handle claims challenges and 401 responses that instruct the client to reauthenticate.
Your token cache can contain “valid” tokens that are now rejected by the resource.

If you build internal enterprise apps, CAE-aware design is one of the most underappreciated differences between “works in dev” and “survives security policy changes.”

Step 4: Practical configuration patterns that survive real environments

Pattern 1: High-risk apps (finance, HR) on unmanaged devices

Goal: reduce session persistence without crushing productivity.

Conditional Access:
- Require strong authentication
- Set sign-in frequency to a shorter window for these apps
- Set persistent browser session to “never persistent” for unmanaged/shared devices
Optionally add token protection where applicable to reduce replay risk.

This is where “token lifetime” is really “how long are we willing to accept yesterday’s trust context?”

Pattern 2: Admin roles

Goal: make privilege elevation painful enough to be safe.

Use tighter sign-in frequency for admin portals and admin roles.
Avoid relying on “remember MFA” style settings; Microsoft guidance pushes toward Conditional Access session controls.

Pattern 3: Users complain “I never get prompted for MFA anymore”

This is often not a bug. It’s an expected result of long-lived session trust. If your policy intent is “MFA daily,” you need:

A sign-in frequency control (and careful targeting)
A clear stance on persistent browser sessions
Acceptance that desktop apps and browsers might differ based on client type and resource targeting (as practitioners note).

Pattern 4: Incident response (lost laptop)

Goal: stop refresh-based persistence quickly.

Revoke sign-in sessions (Graph API revokeSignInSessions)
Combine with CAE-enabled services for faster enforcement
Communicate clearly: “this may take a few minutes” and “existing tokens may persist briefly without CAE.”

What Entra will do “no matter what”

Entra prefers short-lived access + renewable sessions

Even if you force longer access token lifetimes in narrow cases, the ecosystem is optimized for frequent renewal. This is a security and scalability choice.

Policy changes can create delayed effects

Admins expect toggling Conditional Access to immediately change all user experiences. In reality:

users often feel changes at next token renewal
browser sessions may persist until the next interaction triggers a challenge
CAE makes some changes feel immediate, but only where supported

“Session lifetime” is a multi-layer negotiation

Session controls, refresh behavior, client type, and resource capabilities all negotiate the real-world outcome. This is why “we set sign-in frequency to 1 day” can still yield users who appear signed in longer in certain flows—until a renewal boundary is crossed.