Most explanations of refresh token rotation stop at "the old token gets swapped for a new one." That's true, but it skips the part that actually matters: how does the authorization server know a stolen token was used before the legitimate client tries to use it? The answer is a small piece of state most engineers never think about — a token family — and the reuse-detection algorithm built on top of it. Let's open it up.
The problem rotation alone doesn't solve
A static, long-lived refresh token is a bearer secret with an unlimited replay window. If it leaks — from a compromised mobile device, a logged network request, a misconfigured CI cache — an attacker holds a valid credential for as long as the token's TTL allows, often 30-90 days, with zero signal to the legitimate owner.
Rotation on its own only shrinks the window: every refresh call returns a new refresh token and burns the old one. That's better, but if you stop there, an attacker who grabs a token can still race the real client, use it once, and the server has no way to tell "attacker used it" apart from "the app used it."
The piece that actually catches theft is reuse detection, and it requires the server to track lineage, not just validity.
