Refresh Token

What is a refresh token?

A refresh token is a long-lived credential whose only job is to obtain new short-lived access tokens without making the user log in again. It’s half of a deliberate two-token design in OAuth 2.0/OIDC: the access token is short-lived (minutes to an hour) and sent with every API request; the refresh token is long-lived (days to months) and used rarely — only to mint fresh access tokens when the current one expires. This split lets users stay logged in for a long time (good UX) while keeping the frequently-transmitted access token short-lived (good security), so the two goals that would otherwise conflict are both satisfied.

Why the two-token split exists

The design solves a real tension. If you used a single long-lived token for API calls, a good user experience (staying logged in) would require a powerful credential to be sent on every request and stored on the client for a long time — and since access tokens are typically bearer tokens (possession = access), that long-lived, widely-transmitted token would be a fat, long-lasting target: steal it once and you have durable access. If instead you made the token short-lived for safety, users would have to re-authenticate constantly (bad UX). The refresh token resolves this by separating concerns: the access token is short-lived and exposed often (sent on every API call), so if it’s stolen it’s useful only briefly before it expires; the refresh token is long-lived but exposed rarely (only sent to the auth server’s token endpoint to get new access tokens, never to resource APIs), so it has far less exposure surface. The user stays logged in because the app silently uses the refresh token to get new access tokens in the background; security is preserved because the powerful long-lived credential is used sparingly and the constantly-used credential is short-lived. When the refresh token itself finally expires or is revoked, the user must log in again.

Protecting refresh tokens — because they’re the crown jewels

The flip side of a long-lived credential is that a stolen refresh token is a serious compromise — it can be used to mint fresh access tokens for as long as it remains valid, potentially a very long time, so it’s a high-value target that demands strong protection. The disciplines that matter: store it securely — never in a place accessible to XSS (not plain localStorage for sensitive apps); on the web, httpOnly cookies or secure backend storage are preferred, and on mobile, the platform’s secure keystore/keychain; support revocation — the auth server must be able to invalidate a refresh token (on logout, on suspected compromise, on password change) so a leaked one can be killed; and critically, use refresh token rotation — each time a refresh token is used, the server issues a new one and invalidates the old, so a refresh token is single-use. Rotation enables reuse detection: if an old (already-rotated) refresh token is presented, the server knows it was likely stolen and can revoke the entire token family, cutting off an attacker who grabbed a copy. This is now a standard best practice for public clients (SPAs, mobile). Refresh tokens should also be transmitted only over TLS and never exposed to resource servers or URLs. The recurring mistakes: storing refresh tokens where XSS can read them, issuing long-lived refresh tokens without rotation and reuse detection (so a stolen one grants lasting access undetected), no revocation mechanism, and — conceptually — treating the refresh token as just another token rather than the most sensitive credential in the flow.

What people get wrong

• Insecure storage — a refresh token exposed to XSS (e.g., plain localStorage) hands attackers durable access; use httpOnly cookies, backend storage, or the mobile secure keystore.
• No rotation or reuse detection: long-lived refresh tokens without single-use rotation let a stolen token mint access tokens indefinitely and invisibly — rotation plus reuse detection catches theft.
• No revocation — without the ability to invalidate refresh tokens on logout or compromise, you can’t cut off a leaked one before its long lifetime expires.

Primary source: OAuth 2.0 Security Best Current Practice (refresh tokens)