OAuth Token Lifecycle: Access & Refresh Tokens, Rotation, Revocation

OAuth Token Lifecycle

Obtaining tokens is only the beginning. In any OAuth system, tokens have to be validated by APIs, refreshed as they expire, stored safely by clients, and revoked when users log out or credentials are compromised. The design choices (how long access tokens live, whether they're self-contained JWTs or opaque references, how refresh tokens rotate) trade security against performance and user experience.

Short-lived access tokens plus rotating refresh tokens are the modern default. They limit the damage of a stolen token while keeping users signed in for as long as the session policy allows.

TL;DR

Access tokens: short-lived (typically 5–60 minutes), presented to APIs as bearer tokens.
JWT access tokens are validated locally (signature, issuer, audience, expiry); opaque tokens are validated via introspection.
Refresh tokens: longer-lived, used only at the token endpoint to get new access tokens. Rotate them on every use and detect reuse.
Revocation: revoke refresh tokens at logout (RFC 7009). JWT access tokens usually stay valid until expiry, so keep them short.
Store tokens server-side where possible, in secure OS storage on mobile, and avoid localStorage in browsers.
Handle expiry proactively (refresh early) and reactively (retry once on 401), with single-flight refresh.

Quick Example

A refresh request with rotation:

A client-side helper that refreshes once and shares the result across concurrent callers (TypeScript, server or BFF side):

Core Concepts

Access Token Formats

The JWT profile for access tokens (RFC 9068) standardizes claims like iss, sub, aud, exp, scope, and client_id. Many systems use JWTs for performance and keep lifetimes short to bound revocation lag. See JWT.

Validating Access Tokens at APIs

Resource servers must check:

Signature (JWT) or an active introspection result (opaque).
Issuer matches the trusted authorization server.
Audience includes this API. Reject tokens meant for other APIs.
Expiry (exp) and not-before (nbf), with small clock skew.
Scopes and claims authorize the specific operation. See broken access control.

Lifetimes

Refresh Tokens and Rotation

Refresh tokens let clients get new access tokens without user interaction. Because they're long-lived and powerful:

Rotation: each use returns a new refresh token and invalidates the old one.
Reuse detection: if an already-used refresh token is presented again, the server assumes theft and revokes the whole token family, logging the session out.
Sender-constraining: bind refresh tokens to the client via client authentication, DPoP, or mTLS, so stolen tokens can't be used elsewhere. See OAuth security.
Absolute and idle timeouts cap session length.

Public clients (SPAs, mobile) should receive refresh tokens only with rotation or sender constraints. The offline_access scope typically requests them.

Revocation

Token revocation endpoint (RFC 7009): clients revoke refresh tokens (and opaque access tokens) at logout.
Server-side revocation: admins disable users or clients, sessions are terminated, and passwords are changed. Authorization servers then invalidate the relevant refresh tokens.
JWT access tokens can't be "un-issued". Options are short lifetimes, a denylist of token IDs (jti) for critical cases, or introspection for high-sensitivity APIs.

Client-Side Storage

See OAuth authorization code with PKCE for the BFF pattern.

Handling Expiry

Proactive: refresh shortly before expires_in elapses.
Reactive: on a 401 with WWW-Authenticate: Bearer error="invalid_token", refresh once and retry.
Single-flight refresh: when many concurrent requests notice expiry, perform one refresh and share it. Parallel refreshes with rotation can invalidate each other and log the user out.
Refresh failure: clear the session and redirect to login gracefully.

Best Practices

Keep Access Tokens Short-Lived

Short lifetimes bound the impact of leaks and make revocation lag acceptable. Combine them with refresh tokens for a smooth UX.

Rotate Refresh Tokens and Detect Reuse

Rotation plus reuse detection turns refresh token theft into a detectable event that terminates the session, rather than silent long-term access.

Validate Audience Everywhere

Every API should accept only tokens issued for it. Audience checks prevent tokens obtained for one service from being replayed against another.

Log Token Events

Record token issuance, refresh, revocation, and reuse detections with client and user context. They're essential for incident investigation. See audit logging.

Common Mistakes

Long-Lived JWT Access Tokens

A 30-day JWT access token that can't be revoked is effectively a password that works until it expires. Use minutes, not days.

Refreshing in Parallel With Rotation

Five tabs or requests each refreshing with the same token trigger reuse detection, and log the user out. Coordinate refreshes (single-flight, or a BFF holding tokens server-side).

Storing Tokens in localStorage

Any XSS vulnerability, including one in a third-party script, can read localStorage and exfiltrate tokens. Keep tokens server-side, or in memory.

FAQ

How long should access tokens last?

Commonly 5–15 minutes for sensitive APIs and up to an hour for lower-risk ones. Shorter tokens reduce the window for misuse and revocation lag, at the cost of more frequent refreshes, which are cheap with refresh tokens.

What is refresh token rotation?

Each time a refresh token is used, the authorization server issues a new one and invalidates the old. If an old token is presented again, a sign it was stolen, the server can revoke the entire session. It limits the value of stolen refresh tokens.

Can I revoke a JWT access token?

Not directly. It remains valid until expiry, because APIs validate it locally. Mitigations: short lifetimes, revoking the refresh token so no new access tokens are issued, a jti denylist for emergencies, or opaque tokens with introspection for APIs that need immediate revocation.

Should I use JWT or opaque access tokens?

JWTs let APIs validate without network calls, which suits microservices and scale. Opaque tokens hide claims and allow immediate revocation via introspection. Many systems use JWTs with short lifetimes, and introspection or opaque tokens for especially sensitive APIs, or for tokens leaving trust boundaries.