How would you implement refresh token rotation?

Implement refresh token rotation by issuing a new refresh token each time the access token is refreshed, invalidating the old one, and storing token fingerprints in a database with user association to detect and prevent replay attacks.

Refresh token rotation is a security enhancement where each access token refresh request returns a brand new refresh token, and the previously used refresh token is revoked. This prevents an attacker who steals a refresh token from using it indefinitely, because once the legitimate client refreshes, the old token becomes invalid. Additionally, the server can detect token replay: if an old refresh token is ever used after a new one has been issued, it indicates theft, and the server can revoke all tokens for that user and trigger a security alert.

Refresh Token Rotation Implementation (Node.js/Express + PostgreSQL)

Why Refresh Token Rotation Improves Security

1
Limits lifetime of a stolen refresh token: even if an attacker steals a refresh token, it becomes invalid after the legitimate client refreshes (e.g., every 15 minutes).
2
Detects token theft: if an attacker tries to use an old refresh token after rotation, the server sees the token is already revoked and can take action (e.g., revoke all user tokens, alert security team).
3
Prevents replay attacks: each refresh token can be used exactly once, making replay impossible.
4
Enables better audit: every refresh operation is logged and creates a new token, providing a clear token usage trail.

Best Practices

1
Store only a hash of the refresh token identifier in the database, never the plain token (defense in depth).
2
Use short access token lifetime (e.g., 15 minutes) to force frequent refreshes and minimize the window for access token abuse.
3
Set refresh token expiration appropriately (e.g., 7 days) and allow sliding expiration with rotation.
4
Implement token reuse detection: if an old refresh token is presented after rotation, revoke all tokens for that user and optionally force re-authentication.
5
Use HTTP‑only, Secure, SameSite=Strict cookies to store refresh tokens, preventing XSS and CSRF attacks.
6
Consider using a token family approach instead of one-time tokens if you need offline capability (less common).

When implementing refresh token rotation in a production system, you must also consider concurrency: if a user makes multiple refresh requests simultaneously (e.g., due to network retries), ensure your database updates are atomic to avoid invalidating a token that was just rotated. Use row-level locking or optimistic concurrency control. Additionally, implement proper cleanup of expired refresh tokens via a scheduled job to keep the database lean.