azureblog.co.uk
← cd ~/posts

Configurable token lifetimes are GA: when to shorten them (and when not to)

You can now set the lifetime of access, ID and SAML tokens per application. Useful for sensitive apps, but there are better tools for most session problems.

2 min read✓ checked 29 Apr 2026Entra ID · Security · What's new
On this page
  1. When it helps
  2. When it doesn't
  3. Practical guidance
  4. Choosing a lifetime
  5. Testing a change

Token lifetime policies let you change how long access tokens, ID tokens and tokens from the Microsoft identity platform stay valid. You create a policy and assign it to specific applications or .

Token lifetime policy

  • Access token lifetime
  • ID token lifetime
  • SAML token lifetime
  • Per app or service principal

Conditional Access session controls

  • How often users sign in again
  • Persistent browser sessions
  • Applied by policy to users and apps

Continuous access evaluation

  • Near-real-time revocation
  • Reacts to account and location changes
  • In supporting services
Which tool controls which part of a session.

When it helps

  • Sensitive applications. A shorter access token lifetime means a stolen token is useful for less time.
  • SAML apps with long sessions. Controlling the SAML token lifetime can tighten how long an assertion is accepted.
  • Long-running automation. In some cases a longer access token lifetime reduces token refresh churn.

When it doesn't

Token lifetime policies don't control refresh tokens or session tokens. If the problem is "how often should users sign in again?", the answer is session controls:

  • Sign-in frequency sets how often users must reauthenticate.
  • Persistent browser session controls whether the browser stays signed in after it closes.
  • Continuous access evaluation (CAE) lets supporting services revoke access quickly when something changes, such as a disabled account or a new location, without needing short tokens everywhere.

Practical guidance

  • Change lifetimes only for specific apps with a clear reason. Don't apply a short lifetime tenant-wide.
  • Test with the app owner. Some apps behave badly when tokens expire mid-session.
  • Document the policy and why it exists, so the next engineer doesn't remove it or copy it blindly.

Choosing a lifetime

What problem are you solving?
Users stay signed in too longUse Conditional Access sign-in frequency instead
Stolen tokens should be useful for less timeShorter access token lifetime for that app
Disabled users keep access too longContinuous access evaluation is the better fix
Do you need a token lifetime policy at all?

Testing a change

  1. Create the policy and assign it to a test copy of the app, or the real app with a pilot group.
  2. Sign in, then decode the access token with the JWT decoder and compare iat and exp to confirm the new lifetime.
  3. Use the app past the lifetime to make sure it renews tokens quietly instead of failing.
  4. Roll out to everyone and record why the policy exists.
Sources

Related posts