Token Lifetime Policy Design Guide

Every token lifetime is a bet: too long and a stolen token stays useful for months, too short and pipelines, integrations and users break at the worst moment. Most organisations never make that bet deliberately. They inherit vendor defaults, add exceptions when something fails, and end up with refresh tokens that live for years beside access tokens that expire every hour. This guide sets out how to design a token lifetime policy on purpose: which lifetimes matter, what the standards and major platforms actually allow, how to tier lifetimes by risk, and how to roll out shorter lifetimes without outages. It is written for identity architects, platform engineers and NHI programme owners who set or review token settings for people, workloads and third-party integrations.

Key takeaways

The refresh token is the real lifetime. An access token that expires in an hour gives little protection if the refresh token behind it never expires, as the Gainsight tokens created between 2017 and 2023 showed.
Lifetime is one control among four. Expiry works with audience restriction, sender-constraining and revocation; short lifetimes compensate for weak revocation, not for broad scopes.
Tier by risk, not by application. Define a small set of lifetime tiers (privileged, standard, workload, integration) and map every token issuer to one, with documented exceptions.
Workloads should not hold long-lived tokens at all. Federation and platform-issued credentials (STS, GCP short-lived tokens, Kubernetes bound tokens, GitHub App installation tokens) make one-hour or shorter lifetimes practical.
Reliability is a design input. Renew early, cache tokens correctly and test expiry in staging, so shorter lifetimes do not become the outage that forces everyone back to long ones.

Which lifetimes a policy must cover

"Token lifetime" is several separate settings, often owned by different teams. A policy that only sets access token lifetime leaves most of the exposure untouched. Map each of these explicitly.

Lifetime	What it bounds	Typical control point	Exposure if too long
Access token lifetime	How long one token is accepted by an API	Authorisation server or IdP policy	Replay of a leaked token from logs, memory or proxies
Refresh token absolute lifetime	How long a grant can keep minting access tokens	Authorisation server, SaaS connected-app settings	Persistent access long after the person or vendor relationship changed
Refresh token idle timeout	How long an unused grant survives	Authorisation server	Forgotten integrations that still work when stolen
Web session overall and inactivity timeout	How long a signed-in browser session lasts	Application and IdP session settings, Conditional Access	Stolen session cookies replayed (ATT&CK T1539)
Workload credential lifetime	How long a cloud or cluster credential is valid	STS, cloud IAM, Kubernetes API server	Exfiltrated credentials used from outside the environment
Personal access token and API key expiry	How long a static token works	SaaS and developer platform policy	Tokens leaked in code that still work years later
Signing key lifetime	How long tokens signed by one key can be trusted	IdP key rotation, JWKS publication	Forged tokens if a key is stolen (T1606.002 for SAML)

The broader controls around stealing and replaying tokens, including JWT validation, are in the Token and Session Security Guide. This guide concentrates on the lifetime decisions themselves.

What the standards say

RFC 9700 (OAuth 2.0 Security Best Current Practice, January 2025): section 2.2.2 states that refresh tokens for public clients must be sender-constrained or use refresh token rotation. Section 2.3 says access tokens should be audience-restricted to a specific resource server, using the aud claim, the resource parameter (RFC 8707) and narrow scopes. Sections 2.2.1 and 4.10.1 recommend sender-constraining with mutual TLS (RFC 8705) or DPoP (RFC 9449), and note that this weakens if an attacker steals both the token and its key.
NIST SP 800-63B-4 reauthentication: sessions have an overall timeout and an inactivity timeout, and the session ends when either expires. At AAL2 the overall timeout should be no more than 24 hours and the inactivity timeout no more than 1 hour. At AAL3 the overall timeout shall be no more than 12 hours, with inactivity of no more than 15 minutes. At AAL1 the overall timeout should be no more than 30 days. The same section allows limits to be extended where device-bound session technology is used, which is the formal basis for trading binding against lifetime.
NIST SP 800-53 Rev. 5: AC-12 Session Termination, IA-11 Re-authentication, SC-23 Session Authenticity and IA-5 Authenticator Management are the controls an auditor will map a lifetime policy to.

None of these documents gives a single "correct" number for API access tokens. That is deliberate: the right value depends on what else protects the token.

Platform settings and their real limits

Policy must fit what platforms allow. These values are from vendor documentation; check them again before you write them into a standard, because defaults change.

Platform	Setting	Documented range or default	Design note
Microsoft Entra ID	`AccessTokenLifetime` in a `tokenLifetimePolicy` (Microsoft Graph)	10 minutes to 1 day; default access tokens are a random 60 to 90 minutes; ID and SAML2 tokens 1 hour	Applies to access, ID and SAML2 tokens. An organisation-level policy overrides an application-level one
Microsoft Entra ID	Refresh and session tokens	Not configurable since 30 January 2021; default max inactive time 90 days, max age until revoked	Control user sign-in frequency with Conditional Access instead. Managed identities do not support token lifetime policies
Microsoft Entra ID	Continuous access evaluation (CAE)	Access tokens may extend to 24 to 28 hours when client and resource support CAE	Longer lifetime is acceptable because revocation is near real time for events such as account disablement
AWS STS	`DurationSeconds` on `AssumeRole`; role `MaxSessionDuration`	900 to 43,200 seconds, default 3,600; role maximum 1 to 12 hours; role chaining capped at 1 hour	Requests above the role maximum fail, so changing the role setting can break callers
Google Cloud IAM	`generateAccessToken` lifetime	Default maximum 1 hour, extendable to 12 hours only via the `constraints/iam.allowServiceAccountCredentialLifetimeExtension` organisation policy; OIDC ID tokens 1 hour	Treat any service account on the extension list as an exception with an owner
Okta authorisation servers	Access policy rule: access and refresh token lifetimes	Set per grant type, user and scope; rules evaluated in priority order, first match wins	Rule order matters: a broad rule above a strict one silently wins
GitHub	App installation access token; organisation PAT policy	Installation tokens expire after 1 hour and can be limited to up to 500 repositories and named permissions; fine-grained PATs default to a 366-day maximum, classic PATs have no expiry requirement by default	Organisation maximums block non-compliant tokens rather than revoking them, so expect rejected API calls on rollout
Kubernetes	Projected service account token `expirationSeconds`	Default 1 hour, minimum 10 minutes; the kubelet refreshes the token before expiry	Applications must re-read the token file rather than caching it at start-up

Designing lifetime tiers

A workable policy has four or five tiers that every issuer maps to. The values below are a reasoned starting point, not a standard; adjust them to your platforms and record why.

Tier	Examples	Access token or credential	Refresh or session	Required compensating controls
1. Privileged human	Cloud console admins, IdP admins, PAM sessions	Platform minimum, 10 to 60 minutes	Overall 12 hours or less, inactivity 15 minutes (AAL3 values)	Phishing-resistant MFA, managed device, re-authentication for sensitive actions
2. Standard workforce	Email, collaboration, internal apps	Platform default (around 1 hour), or longer only with CAE	Overall up to 24 hours, inactivity 1 hour for AAL2 apps; longer on bound, managed devices	Conditional Access, revocation on risk events
3. Workload, same platform	Pods, functions, VMs using platform identity	1 hour or less, issued automatically	No refresh token: the platform reissues	Audience restriction, least-privilege role, no static fallback key
4. Workload, cross-platform	CI/CD to cloud, cloud to cloud	15 to 60 minutes via federation	None: re-federate per job or per hour	Trust policy bound to repository, branch or workload subject
5. Third-party integration	SaaS connected apps, vendor OAuth clients, AI agents acting for users	Platform default, 1 hour or less	Absolute refresh lifetime of 90 days or less with idle timeout and rotation; re-consent on expiry	IP restriction where the platform supports it, scope review, named business owner

Static tokens: personal access tokens and API keys that cannot be federated get an enforced maximum (for example 90 days for write access, never "no expiry") and an owner. See the Secrets Rotation Runbook Template.
Exceptions: every lifetime above a tier's ceiling needs a named owner, a reason, a compensating control and an end date. Review exceptions quarterly.
Agents: AI agents that call APIs on a user's behalf belong in tier 5 if a vendor runs them and tier 4 if you do. Delegated tokens should be shorter-lived than the user's own. See the OAuth Token Exchange and Delegation Guide.

Trade-offs and decision guidance

Short lifetime or fast revocation?

Short lifetimes cap exposure automatically but cost token traffic and resilience. Fast revocation lets tokens live longer but only works if every resource checks it. Choose short lifetimes for self-contained JWTs that resource servers validate locally, because they cannot be recalled. Choose longer lifetimes with revocation where the platform enforces it at the resource, as with Entra CAE or opaque tokens checked by introspection. Do not assume revocation works because the IdP offers a revoke button: test whether a revoked token is still accepted by each API.

Bearer or sender-constrained?

A bearer token is useful to whoever holds it, so its lifetime is its main defence. A token bound with DPoP or mTLS is useless without the private key, which justifies a longer lifetime when the key sits in hardware or a non-exportable store. If the key sits in the same file as the token, binding adds little.

Rotation or absolute expiry for refresh tokens?

Rotation, where each use returns a new refresh token and reuse of an old one revokes the chain, detects theft only if the legitimate client keeps using its token. Absolute expiry limits a stolen token even when the victim is idle. Use both for third-party integrations; some of the tokens used against Gainsight customers had been issued years earlier.

Small and large organisations

Small teams: rely on platform defaults where they are already short (STS, GCP, GitHub Apps), remove static cloud keys in favour of federation, and set organisation-wide PAT maximums. That removes most long-lived tokens with little engineering.
Large estates: need a token inventory per issuer, the tier mapping above, an exceptions register and automated checks in infrastructure-as-code pipelines that reject a role MaxSessionDuration or token policy above its tier.

Designing for reliability

Most pressure to lengthen lifetimes comes from outages caused by expiry. Fix the cause instead.

Renew early: clients should refresh at a fraction of the lifetime (for example at 75 to 80 percent) with jitter, not when the API returns 401.
Read expiry from the response: use expires_in or the exp claim. Entra deliberately randomises default access token lifetimes between 60 and 90 minutes, so hard-coded one-hour assumptions fail.
Re-read mounted tokens: Kubernetes and similar platforms replace token files in place; libraries that load the token once at start-up fail when it expires.
Size long jobs correctly: a batch job that runs longer than its credential must re-assume the role mid-run. Remember AWS role chaining caps sessions at one hour regardless of DurationSeconds.
Plan for IdP outages: very short lifetimes make every workload depend on the token service being available. Keep workload lifetimes long enough to ride through a short issuer outage, and monitor issuer health as a dependency.
Clock skew: validate with a small leeway (a few minutes). Entra adds a five-minute skew to SAML NotOnOrAfter when a policy applies.

Rolling out a lifetime policy

Inventory issuers and current values. List every IdP, authorisation server, cloud STS, SaaS connected-app setting and developer platform, with current access, refresh and session values. Include vendor-held tokens.
Find the long tail first. Query for refresh tokens and PATs older than your proposed ceiling and grants unused for 90 days. These are usually the biggest risk and the cheapest to remove.
Agree tiers and exceptions. Publish the tier table, the exception process and who approves.
Test in staging with compressed lifetimes. Set lifetimes far below target (for example 10 minutes) in a test environment to flush out clients that cache tokens or ignore expires_in.
Roll out by ring. Apply new values to an application-level policy for a pilot group before the organisation default. In Entra, remember that an organisation-level policy overrides application policies.
Revoke the legacy tokens. Revoke refresh tokens and PATs beyond the ceiling, with notice to owners, and require re-consent for integrations.
Roll back cleanly if needed. Keep the previous policy object and change record; rolling back is reassigning the old policy or role setting, but revoked tokens cannot be restored, so revoke only after the pilot is stable.
Enforce in code. Add policy checks to infrastructure-as-code review so new roles, apps and service accounts inherit the tier ceiling.

Detection and measurement

Log token issuance and use at the issuer and the resource: Entra sign-in logs (including non-interactive and service principal sign-ins), AWS CloudTrail AssumeRole events, Google Cloud audit logs for GenerateAccessToken, Okta system log token events and SaaS API event logs. Watch for refresh tokens used from new networks, access tokens presented after the subject was disabled, and bulk API activity by integrations (ATT&CK T1550.001, Use Alternate Authentication Material: Application Access Token).

Long-lived token count: refresh tokens, PATs and API keys older than the tier ceiling. Target zero outside the exceptions register.
Median credential age at use: for workloads, how old credentials are when presented. A falling value shows federation is replacing static keys.
Dormant grant count: third-party grants unused for 90 days.
Time to revoke: from decision to the last accepted use of a revoked token, measured in tests.
Expiry-related incidents: outages caused by expired tokens. If this rises, fix renewal logic rather than lengthening lifetimes.
Exceptions past their end date: should be zero.

Common failure patterns

Setting access token lifetime and ignoring refresh tokens: the Gainsight Salesforce breach involved 285 OAuth tokens created between October 2017 and August 2023; Gainsight's own finding, as reported, was that its tokens had been allowed to live too long.
Vendor-held grants with no end date: in the Salesloft Drift breach, customer OAuth tokens stored in one vendor environment kept working until Salesloft and Salesforce revoked all Drift access and refresh tokens on 20 August 2025, after data export had begun on 8 August.
Long lifetimes as an outage fix: a pipeline fails at expiry, someone sets the role maximum to 12 hours, and it never comes back down.
Exceptions that never expire: service accounts added to a lifetime extension policy for a migration and left there.
Classic tokens left unconstrained: an organisation sets a fine-grained PAT maximum but leaves classic PATs with no expiry requirement.
Short lifetimes without strict validation: a ten-minute token accepted by every API in the estate is still a ten-minute master key. Pair lifetime with audience restriction.

Where it sits in frameworks

Framework	Reference	How a lifetime policy supports it
NIST CSF 2.0	PR.AA-01, PR.AA-03, PR.AA-05	Credentials for users and services are managed, authenticated and limited
NIST SP 800-53 Rev. 5	AC-12, IA-11, SC-23, IA-5	Session termination, re-authentication, session authenticity, authenticator lifetime
NIST SP 800-63B-4	AAL reauthentication requirements	Overall and inactivity timeouts by assurance level
IETF	RFC 9700 sections 2.2 and 2.3	Refresh token rotation or binding, audience restriction
MITRE ATT&CK	T1528, T1539, T1550.001, T1606.002	Token theft, cookie theft, token replay and SAML token forgery that lifetime limits contain

Practitioner checklist

Inventory every token issuer and record access, refresh, session and static token lifetimes.
Publish lifetime tiers covering privileged, workforce, workload and third-party tokens.
Set an absolute lifetime and idle timeout for every third-party refresh token, and revoke grants beyond it.
Replace static workload keys with federated or platform-issued credentials of one hour or less.
Set organisation maximums for fine-grained and classic personal access tokens.
Use Conditional Access sign-in frequency and CAE in Entra rather than legacy refresh token settings.
Test client renewal with compressed lifetimes in staging before production changes.
Measure time to revoke for each token type, not just whether revocation exists.
Keep an exceptions register with owners and end dates, reviewed quarterly.

Token Lifetime Policy Design Guide: Balancing Security and Reliability