Refresh token rotation and scope-based least privilege

A refresh token leaks via a log entry. Without rotation, the attacker silently refreshes new access tokens for months — until the refresh token expires naturally. With rotation, the first time either the attacker or the legitimate client uses the token after its counterpart, the server detects the replay, invalidates the entire chain, and forces re-authentication.

How refresh token rotation works

OAuth 2.1 mandates that every refresh token use issues a new refresh token and invalidates the old one. The server tracks which refresh token superseded which.

Normal flow:

1. Client holds RT1. Presents to /token. Server mints access_token_2 + RT2. Marks RT1 as used, linked to RT2. Client stores RT2.

Under attack:

1. Attacker steals RT1 (via log leak, network capture, etc.).
2. Attacker uses RT1 first → gets access_token_A + RT2. RT1 is now marked used.
3. Legitimate client later presents RT1 (unaware of theft) → server sees RT1 is already used → replay detected.
4. Server revokes the entire chain (RT1, RT2, all descendants). Both attacker and legitimate client lose access. User is forced to re-authenticate.

Without rotation: a stolen RT1 works until its absolute expiry — days to months. With rotation: the window of harm is bounded by the rotation interval — typically minutes to hours until the next legitimate refresh.

Scopes and least privilege

Every access token carries a scope claim — the exact permissions granted at consent time. The app requests a scope set at /authorize; the user sees the consent screen and approves or denies.

Why granular scopes matter:

• read:photos vs read:everything — the photo-printing app should only see photos, not email or calendar.
• Blast radius: if the app is compromised, attackers can only do what the granted scopes allow. read:photos lets an attacker download photos. write:photos delete:photos also lets them destroy them.
• User trust: a consent screen asking for read:photos is reasonable. One asking for full account access is alarming — users decline, and they are right to.

Industry pattern: read scopes are freely granted; write scopes require explicit per-action consent; admin scopes never appear in third-party flows. RFC 9396 (Rich Authorization Requests) extends this further, allowing requests like “transfer up to $500 to account 12345” instead of just write:transfers.

Introspection vs JWT validation: the real tradeoff

When the resource server receives an access token, it must verify it. Two approaches:

Token introspection (/oauth/introspect): real-time call to the IdP per request. Always current — knows about revocations immediately. Costs one extra round trip per request (~5–50ms latency). Required for opaque tokens.

Local JWT validation: the token is a signed JWT. The resource server validates the signature using JWKS. Fast — microseconds. Scalable to millions of RPS. Flaw: cannot see revocations until the token expires. A revoked JWT keeps working for its remaining TTL.

Production pattern: local JWT validation for the hot path + short access token TTL (5–15 minutes, accepting that revocations propagate within that window). For sensitive writes (transfers, deletes), layer introspection on top. A small server-side cache of “recently introspected tokens” (TTL 30s) amortizes the introspection cost.