Refresh Token Rotation: Stay Secure Without Logging Users Out

The pattern behind “stay logged in for 30 days” — and why it’s safer than it sounds.

Real-life analogy

Think of a hotel key card. When you check in, the front desk gives you a card that opens your room for 24 hours. When it expires, you go back and they hand you a new card — and the old one stops working immediately. Even if someone found your old card in the elevator, it’s useless. That’s refresh token rotation.

The problem it solves

Access tokens are like your hotel key — they authenticate you on every request. Make them last too long and a stolen token is a skeleton key. Make them too short and users get logged out constantly.

The fix: keep access tokens short-lived (15 min) and pair them with a long-lived refresh token that silently issues new ones. The catch — rotate that refresh token on every single use.

How it works

1. Login: Server issues a short-lived access token + a long-lived refresh token.
2. Access token expires: Client quietly calls the refresh endpoint — user notices nothing.
3. Rotation: Server issues a brand new access token and a brand new refresh token. Old refresh token is dead.
4. Repeat forever — or until the user logs out.

The hidden superpower: theft detection

Real-life scenario

Imagine someone steals your hotel key card on Monday. By Tuesday morning, you’ve already renewed it at the front desk — so your new card works and theirs doesn’t. But here’s the kicker: if they try to use the old card, an alarm goes off. The hotel knows someone has a card that shouldn’t exist anymore, and immediately locks down your room.

Same idea here. If an attacker tries to use a rotated-away token, your server detects the reuse — and can revoke the entire session family instantly.

Old token used again = someone has it who shouldn’t. Revoke every token from that session immediately.

Three things to get right

1. Store refresh tokens as hashed opaques — not JWTs. JWTs can’t be revoked. A random string whose hash lives in your DB can.
2. Never use localStorage. Any JavaScript on your page can read it. Use HTTP-only cookies — they’re invisible to scripts.
3. Handle race conditions. If three API calls fire at once when the token expires, only one refresh should happen. Use a lock that queues the rest.

A hacker steals your refresh token. Here’s what happens:

Without rotation, it’s a master key. They quietly generate fresh access tokens whenever they want, for days. You never know they’re inside.

With rotation, every token is single-use. The moment anyone uses it — you or the hacker — the other copy dies. If they go first, your app detects the conflict and kills the session. If you go first, their token is already dead on arrival.