Security guide

JWT Refresh Tokens Explained: Expiration, Rotation & Security

A JWT access token is stateless, which makes it both convenient and risky: nothing on the server remembers it, so a stolen token works until it expires. Refresh tokens are the standard fix — a short-lived access JWT backed by a long-lived credential that is rotated on every use. Here is how the lifetimes, rotation and reuse detection actually work in production auth.

Written by Benjamin Rotshtein

Updated August 10, 2026

Download as PDF

What is a refresh token for?

To mint new short-lived access tokens without asking the user to log in again — convenience with a tiny blast radius.

How long should it live?

7–30 days is the mainstream default, often with sliding expiration so active users never notice.

Why rotate it?

Every refresh invalidates the old token, so a stolen one stops working the moment it is used, and reuse detection revokes the whole family.

How do JWT refresh tokens keep users logged in?

When a short-lived access token expires, the client presents the refresh token at the token endpoint and receives a fresh access token — and usually a rotated refresh token too. The refresh token lives only in the browser’s secure storage and never travels with API calls, so a stolen access token stops mattering within minutes.

Why access JWTs must be short-lived

A JWT carries its own identity and can be verified by any service holding the signing key. There is no server record to check, so a leaked access token is fully valid until the exp claim. The defense is a short lifetime: keep the access token at 5–15 minutes so an attacker's window is minutes, not weeks. The refresh token then supplies the convenience without widening that window.

To inspect a token's actual claims — expiry, issuer, audience — paste it into the JWT Decoder. It runs entirely in your browser, so the payload never leaves your machine.

The three-token lifecycle

Refresh token rotation and reuse detection

Rotation means each token exchange mints a new refresh token and invalidates the old one. The normal flow looks like this:

POST /token  { grant_type: "refresh_token", refresh_token: "R1" }
  -> 200 { access_token: "A2", refresh_token: "R2" }   # R1 now dead

# Attacker replaying R1 after it was rotated:
POST /token  { grant_type: "refresh_token", refresh_token: "R1" }
  -> 401, AND the server flags R1 as already used

Reuse detection is the rule that turns a replay into an alarm: if a rotated-out refresh token is ever presented again, treat the entire token family as compromised. Revoke every token issued from that family and force a fresh login. This is what stops an attacker who stole a token from quietly staying logged in.

Where to store each token

• Access token: keep in JavaScript memory if you can — it is only needed for the next API call, and XSS cannot read memory it can't reference. A refresh-on-401 flow re-mints it transparently.
• Refresh token: an httpOnly; Secure; SameSite=Lax cookie for browsers, or the OS secure keychain for native apps. httpOnly keeps it invisible to XSS.
• Never localStorage: a single XSS payload reads it, and a stolen refresh token is a persistent session the user cannot revoke without a logout-everywhere trip.

Expiration: short expiry vs sliding

Two patterns dominate. Fixed expiry (e.g. 30 days) logs everyone out on a schedule and is simplest to reason about. Sliding expiration extends the refresh token's life each time it is used, so active users stay logged in indefinitely while idle sessions expire on their own. Sliding fits subscription products; fixed fits anything with compliance limits. Keep the exp claim on the access JWT strictly enforced on the server — trusting the client is how expired tokens slip through.

Ready to inspect a real token?

Frequently asked questions