Skip to main content
Identity Authority
Category: Tokens & Sessions

Refresh Token

Simply put

A refresh token is a credential a client application holds so it can obtain new access tokens after the current one expires, without prompting the user to sign in again. Because it is typically longer-lived than an access token, it lets a user stay signed in over an extended period while short-lived access tokens are renewed behind the scenes.

Formal definition

In OAuth 2.0, a refresh token is a long-lived credential issued to a client that is used at the token endpoint, via the refresh token grant, to obtain new access tokens (and, in many deployments, a new refresh token pair) when the current access token expires, without requiring the user to re-authenticate. It is distinct from an access token (which authorizes access to protected resources) and, in OpenID Connect, from an ID token (which conveys authentication claims); a refresh token itself is not intended to authorize resource access. The renewal exchange gives the authorization server an enforcement point to reject reissuance, for example when a user's password or access has changed, depending on configuration and server policy.

Why it matters

Refresh tokens resolve a core tension in token-based access: security favors short-lived access tokens that limit the blast radius of a leaked credential, while usability favors keeping a user signed in across an extended session. By holding a longer-lived refresh token, a client can silently renew short-lived access tokens at the authorization server's token endpoint, so the user experiences continuity while the resource-facing credentials remain brief. This division of labor is what makes short access token lifetimes practical in most OAuth 2.0 and OpenID Connect deployments.

The renewal exchange is also a control point, not just a convenience. Because the client must return to the authorization server to obtain each new access token, that server gets a recurring opportunity to reject reissuance, for example when a user's password or access has changed, depending on server policy and configuration. Without refresh tokens and their renewal step, a still-valid long-lived access token would continue to grant access with no such intervening check.

That same longevity makes refresh tokens a high-value target. A refresh token is a credential that can be exchanged for fresh access tokens without user interaction, so a stolen refresh token can extend an attacker's access well beyond the life of any single access token. This is why refresh token handling, secure storage, transport protection, and server-side revocation and reissuance policy, warrants the same scrutiny given to the credentials it can mint, and why the renewal step's ability to reject a compromised or stale token matters operationally.

Who it's relevant to

IAM Engineers and Application Developers
Teams integrating clients with an authorization server rely on refresh tokens to keep users signed in while using short-lived access tokens. They must decide how refresh tokens are stored and transmitted, how the refresh token grant is invoked at the token endpoint, and how to handle the new token pair that many deployments return on each renewal.
Security Architects
Architects weigh the trade-off between short access token lifetimes and refresh token longevity, and treat the renewal exchange as an enforcement point where reissuance can be rejected, for example after a password or access change. They also account for the elevated value of a long-lived credential that can be exchanged for fresh access tokens without user interaction.
System Administrators and Identity Operations
Operations teams configure and enforce the server-side policies that govern refresh token renewal and rejection, so that changes to a user's password or access can be reflected when the client next attempts to obtain new access tokens. Exact behavior depends on the authorization server's configuration and policy.

Inside Refresh Token

Long-lived credential
A refresh token is a credential issued alongside an access token (typically in OAuth 2.0 and OIDC flows) whose purpose is to obtain new access tokens without requiring the resource owner to re-authenticate. It generally has a longer lifetime than the access token it renews.
Token format
Refresh tokens are commonly opaque strings whose structure is meaningful only to the issuing authorization server, though some deployments issue self-contained (for example JWT-based) refresh tokens. The format is implementation- and profile-dependent and is not mandated to be inspectable by the client.
Association with a grant
A refresh token is bound to a specific authorization grant, client, and typically a scope set granted by the resource owner. When exchanged, the authorization server may issue an access token with the same or a narrower scope, depending on configuration.
Authorization server dependency
Redemption occurs at the authorization server's token endpoint, which validates the refresh token, applies policy, and may enforce client authentication before issuing a new access token (and, in some configurations, a new refresh token).
Rotation state (when enabled)
In deployments using refresh token rotation, each redemption can produce a new refresh token and invalidate the prior one, allowing the server to detect reuse of a superseded token as a possible compromise indicator.

Common questions

Answers to the questions practitioners most commonly ask about Refresh Token.

Does a refresh token authenticate the user?
No. A refresh token does not authenticate a user in the way an ID token or an authentication event does. In OAuth 2.0 it is a credential issued to a client that allows the client to obtain new access tokens (and sometimes a new ID token) without re-running the full authorization flow. The original user authentication happened earlier, at the authorization server; possessing a refresh token typically reflects that a prior authorized session existed, not that the user is being authenticated again at the moment the token is exchanged. Treating refresh token presentation as equivalent to a fresh authentication event conflates delegated authorization with authentication.
Are refresh tokens and access tokens interchangeable?
No. They serve different purposes. An access token is presented to a resource server to gain access to protected resources and is typically short-lived. A refresh token is presented to the authorization server's token endpoint to obtain new access tokens, and is typically longer-lived. A refresh token is generally not accepted by resource servers as a means of access, and an access token cannot be exchanged for new tokens the way a refresh token can. Their lifetimes, audiences, and handling requirements differ, so treating them as one thing tends to lead to insecure storage and validation choices.
How should refresh tokens be stored on the client side?
Storage depends on the client type and deployment context. For confidential clients (such as server-side web applications), refresh tokens are typically kept in server-side, protected storage rather than exposed to the browser. For public clients such as single-page applications and native/mobile apps, storage is more constrained; some deployments use platform-provided secure storage, HTTP-only cookies, or backend-for-frontend patterns to avoid exposing refresh tokens to JavaScript. Because refresh tokens are long-lived credentials, exposure carries higher risk than access token exposure, so the specifics should follow the relevant OAuth 2.0 security guidance and your platform's secure storage capabilities.
What is refresh token rotation and when is it used?
Refresh token rotation is a pattern in which each use of a refresh token at the token endpoint issues a new refresh token and invalidates the prior one. It is often recommended for public clients that cannot keep a client secret, because it helps detect and limit the impact of token theft: if a stolen token is replayed after the legitimate client has already rotated it, the authorization server can detect reuse and revoke the token family. Whether rotation is enforced, and how reuse detection behaves, depends on the authorization server's configuration and vendor implementation.
How can a refresh token be revoked before it expires?
Revocation is handled by the authorization server, which maintains the state governing whether a given refresh token remains valid. Depending on the implementation, revocation may be triggered through a token revocation endpoint, administrative session or grant management, a user-initiated logout or consent withdrawal, credential changes, or reuse detection under rotation. Because refresh tokens are typically validated at the authorization server rather than being self-contained in the way some access tokens are, the server can invalidate them centrally. The exact revocation mechanisms and their propagation behavior vary by vendor and configuration.
How should refresh token lifetime and scope be configured?
Lifetime and scope should be set according to the sensitivity of the resources, the client type, and your risk tolerance. Refresh tokens are typically longer-lived than access tokens, but very long or non-expiring lifetimes increase the window of exposure if a token is compromised. Common considerations include setting an absolute maximum lifetime, applying idle/inactivity timeouts, constraining the scopes a refreshed access token may carry, and binding the refresh token to a specific client. The available controls and their defaults depend on the authorization server and profile in use, so validate behavior against your specific deployment rather than assuming a fixed policy.

Common misconceptions

A refresh token authenticates the user each time it is used.
A refresh token is part of OAuth 2.0's delegated authorization model; redeeming it obtains a new access token based on a previously granted authorization, not a fresh authentication of the user. OAuth 2.0 itself is not an authentication protocol. User authentication is handled separately, for example via OpenID Connect at initial sign-in.
A refresh token and an access token are interchangeable.
They serve different purposes. An access token is presented to a resource server to authorize access to protected resources, while a refresh token is presented only to the authorization server's token endpoint to obtain new access tokens. An ID token (from OIDC) is distinct from both and conveys authentication information about the user.
Because a refresh token may be signed, it is protected from being read.
Signing provides integrity and origin assurance, not confidentiality. A signed self-contained token can still be read unless it is also encrypted. Many deployments instead use opaque refresh tokens whose contents are meaningful only server-side; either way, refresh tokens must be treated as sensitive secrets.

Best practices

Store refresh tokens in secure, confidential storage appropriate to the client type; treat public clients (such as SPAs and native apps) differently from confidential clients, since they cannot safely keep long-lived secrets.
Enable refresh token rotation where supported, and configure the authorization server to detect and revoke on reuse of a superseded token as a potential compromise signal.
Set refresh token lifetimes and idle/absolute expiry according to risk, and provide server-side revocation so tokens can be invalidated on logout, credential change, or suspected compromise.
Bind refresh tokens to the authenticated client (and, where supported by your profile, to sender-constrained mechanisms) so a stolen token cannot be redeemed by a different client.
Scope access tokens issued from a refresh token to the minimum required, and avoid broadening scope on refresh unless policy explicitly permits it.
Verify behavior against your specific authorization server and OAuth 2.0/OIDC profile, since rotation, format, lifetime, and revocation semantics vary by vendor and configuration.
Promotional banner for the Pentest Readiness checklist download