A real incident from the finance app I build solo. The security design
was textbook. That's exactly why it bit me.

The textbook setup

Short-lived access token, long-lived rotating refresh token. Every
time the client refreshes:

1. It presents its refresh token.
2. The server verifies it, revokes it, and issues a brand-new access + refresh pair.
3. The old refresh token is now dead — single use.

And the part everyone recommends (OWASP calls it refresh-token reuse
detection): if a client ever presents a refresh token that's already
been revoked, treat it as theft. An attacker who stole a token and
replayed it would trip this. The safe response is scorched earth —
revoke every session for that user so both the attacker and the
victim get kicked and must sign in fresh.

This is correct. It catches a real attack. Ship it.

The incident

One evening my own app showed me a auth error over a €0.00 balance and
an "add your first account" screen — as if I'd never signed in. The
data was all there on the backend. Only the login was dead.

The audit log told the story. All day: healthy refreshes every ~15
minutes. Then, one refresh, the server saw an already-revoked token,
declared theft, and revoked all sessions. The "attacker"?

Every session in the chain carried the same device id. It was my
phone. My phone was the thief.

How a device robs itself

A same-device replay of its own just-rotated token has completely
benign causes, and they're all common:

• Lost response. The server rotated the token and committed, but the HTTP response never made it back (dropped connection, backgrounded app, dead tunnel). The client still holds the old token and retries it. To the server: a revoked token, replayed.
• A failed local write. The new token pair came back, but writing it to the keychain failed (or raced with app suspension). Next launch, the client presents the previous token.
• Two processes racing. My app and its widget extension both hit a 401 and both refresh with the same token. One wins and rotates it; the other arrives a beat later with what is now a revoked token.

None of these are theft. But "revoked token replayed" looked identical
to theft, so the nuke fired and I logged myself out everywhere.

The insight

Here's the thing I missed: for a same-device replay, the revoke-all
adds almost no security.

Reuse-detection defends against an attacker who exfiltrated a refresh
token and replays it from somewhere else. That "somewhere else" is
the signal. An attacker replaying from the same device, with the same
bound device id, already had full access to the device's storage — the
nuke doesn't save you there; they could just present the live token.

So the theft signal isn't "a revoked token was replayed." It's "a
revoked token was replayed from a different device than the one the
session is bound to."

The fix

Bind sessions to a device id, then scope the scorched-earth response to
the cases that are actually suspicious:

if (session.revokedAt) {
  const sameDeviceBenignReplay =
    session.deviceId !== UNBOUND &&
    session.deviceId === presentedDeviceId &&
    session.revokedReason === "rotated";

  if (!sameDeviceBenignReplay) {
    await revokeAllSessions(session.userId, "theft_detected");
  }
  throw new RefreshError("token_replayed"); // 401 either way
}

• Same device, replaying its own rotated token → plain 401. The client just re-authenticates its refresh normally or picks up the winner's new token. No nuke.
• Different device, or a non-rotation revocation (sign-out), or an unbound session we can't attribute → keep the full revoke-all. Real theft signals still get scorched earth.

Three supporting fixes made it robust:

1. A cross-process refresh coordinator. The app and widget now go through a single-flight mutex (a file lock in a shared container + a notification), so only one refresh is ever in flight per device. The loser waits for the winner's token instead of racing it.
2. Harden the token write. Check the keychain write status, retry once, and log loudly on failure — a silently failed write was one of the replay causes.
3. Never turn a transient failure into a logout. A dropped network or a 5xx on the refresh endpoint must be retryable, not "your session is dead." Only a genuine 401/403 from the auth server means sign out.

Takeaways

• Rotating refresh tokens + reuse detection is still the right design. Keep it.
• But "reused token" is not the same as "stolen token." The stolen signal is reuse from an unexpected device. Bind sessions to a device and let that distinction gate your most destructive response.
• Make client refresh single-flight across every process that shares the credentials, or your own app becomes the attacker.
• Distinguish transient failures from auth rejections everywhere in the refresh path. Logging users out on a network blip is its own outage.

The uncomfortable lesson: a security control that's too eager is
indistinguishable from a bug to the person it locks out. Scope the
blast radius to the actual threat.

I'm building EveryPenny, a private,
multi-currency money tracker for iPhone. This one shipped a fix the
same day — solo means the postmortem and the patch are the same
afternoon. Ask me anything about the auth model in the comments.