A refresh token is a credential an application uses to request a new access token from an authorization server without asking the user to sign in each time.

Access tokens are often deliberately short-lived. Without a way to renew access, a customer could face another sign-in prompt while still using an application. Refresh tokens let the authorization server assess whether access should continue without repeating the full login flow on every renewal.

They are optional in OAuth 2.0, and their lifetime depends on policy. A refresh token may remain valid longer than the access token it replaces, which makes protecting it particularly important.

How refresh tokens renew access

1. An application receives a refresh token alongside an access token when the authorization server permits it.
2. When the application needs renewed access, it sends the refresh token to the authorization server’s token endpoint. The server validates it and authenticates the client where required.
3. If the request is accepted, the server issues a new access token. It may also replace the refresh token.
4. The application uses the access token to call the protected API. It keeps the refresh token for the authorization server rather than sending it to that API.

The request cannot expand access beyond the authorization already granted. If the refresh token has expired or been revoked, the application needs to obtain authorization again.

Rotation and reuse detection

Refresh-token rotation replaces the refresh token after each successful use and invalidates the previous value. The server retains the relationship between tokens so it can detect an attempt to reuse an old one.

Suppose malware copies a customer’s refresh token. If the legitimate application uses it first, the attacker’s later attempt to reuse it can expose the compromise. The server can revoke the active refresh token associated with that sequence, forcing a fresh authorization. Rotation detects reuse; it does not prevent every first use of a stolen token.

For public clients, which cannot keep a client secret confidential, current OAuth security guidance requires rotation or sender-constrained refresh tokens. Sender constraint ties use to proof of possession of a key. The choice needs to fit the application architecture.

Keeping customer access under control

Short access-token lifetimes help only if a stolen refresh token cannot keep renewing access indefinitely. Refresh-token expiration and revocation policy therefore belong in the same design as session handling.

Closing a browser tab is not evidence that tokens have been invalidated. Applications need an explicit response to sign-out and account compromise. Revoking a refresh token prevents further renewal, but already-issued access tokens may remain usable until expiry unless the system also invalidates them and the APIs enforce that change.

Storage matters too. The application must protect refresh tokens according to where it runs, and avoid exposing them in diagnostic logs. A single storage recommendation cannot cover a server application and a mobile app equally well.

Frequently asked questions

How does a refresh token differ from an access token?

A refresh token requests renewed access from the authorization server. An access token is presented to the protected API to request an authorized operation.

Do refresh tokens expire?

They can. Expiration and inactivity limits depend on the authorization server’s policy, and a token can also be revoked before its scheduled expiry.

Does signing out automatically revoke every token?

No. Application logout and token revocation are separate actions. Their relationship must be implemented, including how already-issued access tokens are handled.

Related: OAuth 2.0 · Token-Based Authorization (JWT) · Session Hijacking · Account Takeover (ATO) · Credential Management · Identity Lifecycle