Token Lifetime Best Practices: Access, Refresh, ID, and Session Tokens in 2026

Key takeaways

• Short access tokens (5-15 min) plus longer refresh tokens (days to weeks) is the 2026 default.
• Refresh token rotation is non-negotiable, every refresh issues a new refresh and invalidates the old.
• ID tokens should be short-lived (minutes) and never used for API authorization.
• Session tokens and access tokens have different lifetime calculus.
• Lifetime tuning matters more than algorithm choice for security posture.

Why lifetime matters

The industry has converged because the trade-offs are well-understood. Most managed CIAM ship sensible defaults out of the box; the failures come from teams who tune lifetimes incorrectly, usually too long.

The four token classes

CIAM in 2026 issue several distinct token types, each with different lifetime considerations:

Access tokens. Short-lived bearer credentials presented at API endpoints. Typically JWTs (sometimes opaque). Lifetime: 5-15 minutes is the default; sensitive endpoints shorten further.

Refresh tokens. Long-lived credentials used to obtain new access tokens without re-authenticating. Stored client-side (HTTP-only cookies for web, secure storage for native). Lifetime: days to weeks; with rotation, effectively unbounded for active users.

ID tokens. OIDC identity assertions for the client. Contain user claims (sub, email, name). Used for client-side identity, not API authorization. Lifetime: minutes, they're consumed once at the client and don't need to persist.

Session tokens. Browser cookies binding a user to a server-side session. Different mechanics than OAuth tokens, typically opaque with server-side state. Lifetime: governed by sliding inactivity timeout plus absolute maximum age.

For the JWT vs opaque session token decision, see the session management guide.

Recommended access token lifetimes

Default tiers:

• Standard SaaS APIs: 15 minutes
• High-sensitivity (financial transfers, admin actions): 1-5 minutes, with step-up MFA at action time
• Low-sensitivity (public read APIs): up to 60 minutes
• Service-to-service (M2M, no user): longer is acceptable (1-4 hours), with rotation discipline

Anything longer than 60 minutes for user-issued access tokens needs an explicit justification, the stolen-token exposure window grows linearly with lifetime.

Refresh token rotation

OAuth 2.1 makes rotation a first-class requirement: every refresh issues a new refresh token and invalidates the old. The pattern:

1. Client presents refresh token R1; auth server returns access token A2 + new refresh token R2; R1 is invalidated.
2. Client presents R2 next time; auth server returns A3 + R3; R2 is invalidated.
3. If the auth server ever sees R1 reused (after being invalidated), it's a token-theft signal, invalidate the entire token family and force re-authentication.

This converts a stolen refresh token from a long-term capability into a detectable event. The attacker uses the stolen token; the legitimate user's next refresh uses the now-superseded token; the auth server detects the conflict; both sessions are invalidated.

Rotation is non-negotiable in 2026. Every modern CIAM ships it; legacy deployments without rotation should enable it.

Refresh token lifetime

With rotation enabled, the practical access continuation for active users is effectively unbounded, every refresh extends the chain. The lifetime constraint becomes:

• Inactive timeout. A refresh token unused for N days expires. Common values: 30 days for B2B SaaS, 90 days for mobile apps, shorter for sensitive contexts.
• Absolute maximum. Some teams cap total session age (e.g., 1 year) regardless of activity, forcing periodic re-authentication.

For native mobile apps where re-auth is high-friction, longer lifetimes (90 days to 1 year of inactivity tolerance) are common. For web apps where re-auth via passkey or magic link is low-friction, shorter (14-30 days) is standard.

ID token lifetime

ID tokens are identity assertions for the client, not access credentials. They're consumed once when the client authenticates the user and reads claims like sub, email, name.

Best practice: 5-10 minute lifetime. The client uses the ID token at sign-in and discards it. Long-lived ID tokens are an antipattern, they accumulate as static identity claims on the client and tempt incorrect use as API credentials.

If the client needs ongoing identity, the better pattern is the access token's sub claim or a /userinfo endpoint call.

Session token lifetime

Browser session cookies have different mechanics:

Sliding (idle) timeout. The session is extended on each active request. Typical values: 30 minutes for sensitive apps, 4-8 hours for typical SaaS. After the idle period, the session expires.

Absolute maximum. Capped session age regardless of activity. Typical values: 8 hours for sensitive apps, 30 days for typical SaaS, 90 days for low-sensitivity consumer.

The composite: a session is valid as long as the user remains active AND the absolute cap hasn't been reached. The first to expire wins.

Operational considerations

Clock skew tolerance. Servers and clients have clock drift. Validation should tolerate small skew (~30 seconds) without rejecting valid tokens. Tolerance windows wider than 5 minutes accept replayed tokens long after issuance.

Time zones. Tokens use Unix epoch timestamps; this is universal and skips time-zone bugs. Custom token formats with localized timestamps are an antipattern.

Revocation. JWTs cannot be revoked without a server-side check. Pair JWT access tokens with short lifetimes (so revocation propagates via expiration) plus refresh token rotation (for active revocation via family invalidation). Critical actions (password change, MFA disable) should invalidate all tokens for the user.

Step-up at sensitive actions. Even with valid access tokens, sensitive actions (financial transfer, role change, recovery factor change) should require fresh authentication, token age check or explicit re-auth challenge. See the adaptive auth guide for the broader pattern.

Common antipatterns

• 24-hour access tokens with no rotation. A stolen token grants 24 hours of access; the standard mitigation (short lifetime) was traded away for "fewer refresh round-trips" without compensating measures.
• Refresh tokens without rotation. A stolen refresh token grants long-term access undetectable by the auth server.
• Using ID tokens as access tokens. Tempting because they contain user claims; wrong because they aren't designed for API authorization. Use access tokens for API calls.
• Session cookies without absolute maximum. Sessions live indefinitely; stolen cookies are usable for months.
• No token revocation on password change / MFA change. Account-recovery scenarios leave attacker tokens active despite the defensive password reset.

Defaults that work

A starting point that fits most modern CIAM deployments:

• Access token: 15 minutes
• Refresh token: 30 days, rotation enabled
• ID token: 5 minutes
• Session cookie: 30-minute idle, 30-day absolute
• Step-up freshness window for sensitive actions: 5 minutes

Adjust upward only with explicit justification; downward (more conservative) is generally safer.

For the broader session and token model, see the session management guide and OAuth 2.1 guide.