← All terms
Refresh Token

What is a Refresh Token?

A refresh token is a long-lived credential used to obtain new access tokens silently, keeping users signed in without storing passwords or re-prompting.

Last updated: 15 July 2026

How refresh tokens work

OAuth 2.0 splits a session into two tokens with opposite properties. The access token is short-lived, often minutes, and is presented to APIs on every request. The refresh token is long-lived, is never sent to APIs, and has exactly one job: when the access token expires, the client presents the refresh token to the authorization server's token endpoint and receives a fresh access token, usually together with a new refresh token.

This division limits damage. If an access token leaks, it dies on its own within minutes. The refresh token, which would be the valuable prize, travels only between the client and the authorization server over a single hardened endpoint, where every use can be validated against revocation lists, client identity, and anomaly checks before new tokens are issued.

Why refresh tokens matter

Without refresh tokens, systems face an ugly choice: issue long-lived access tokens that are dangerous when stolen and nearly impossible to revoke, or force users to re-authenticate every few minutes. Refresh tokens dissolve the dilemma, delivering the user experience of a long session with the security profile of short-lived credentials.

They are also the control point for revocation. Because every renewal passes through the authorization server, administrators can cut off a user, device, or application by invalidating the refresh token; the current access token then simply runs out. Refresh token rotation strengthens this further: each use issues a replacement and invalidates the old token, so a stolen token that gets replayed collides with its successor and the server can revoke the entire family.

Refresh tokens in practice

Handling depends on the client type. Server-side applications keep refresh tokens in protected server storage. Native and mobile apps use platform keychains. Browser-based single-page applications are the hardest case, since anything readable by JavaScript is exposed to cross-site scripting; current guidance favors rotation with short refresh token lifetimes, or keeping tokens out of the browser entirely behind a backend-for-frontend.

Operationally, teams should enable rotation and reuse detection, scope refresh token lifetimes to the sensitivity of the application, and tie token revocation into offboarding so disabling a user genuinely ends their access. As an OIDC provider, Monosign issues and manages tokens under centrally defined session and lifetime policies.

Frequently asked questions

What is the difference between a refresh token and an access token?
The access token is the short-lived key presented to APIs on every request; the refresh token is the long-lived credential used only at the authorization server to obtain new access tokens. APIs never see the refresh token, and the access token cannot be used to mint new tokens.
What is refresh token rotation?
With rotation, every refresh issues a brand-new refresh token and invalidates the one just used. If a stolen token is replayed later, the server sees two parties using the same lineage, flags the reuse, and revokes the whole token family, which turns theft into a detectable event.
How long should refresh tokens live?
There is no universal number; it is a policy decision balancing convenience and risk. Consumer applications often allow weeks with rotation, while enterprise and high-sensitivity contexts prefer shorter windows, inactivity expiry, and absolute caps, with immediate revocation wired into offboarding.