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.
- 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.
- 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.
Scenario Questions
0-2 years experience
- 1Suppose you need to add refresh token rotation to an existing login endpoint that currently issues a JWT access token and a static refresh token. Walk me through the steps you would take to modify the flow.
- 2If a user presents a refresh token that has already been used, what should your service return and why?
- 3How would you store the rotating refresh token on the server side so you can verify it on the next request?
2-5 years experience
- 1We noticed that after deploying refresh token rotation, some users are getting logged out unexpectedly when they open the app on two devices simultaneously. How would you investigate and fix this?
- 2Explain the trade‑offs between persisting a token identifier in a database versus using a signed JWT as the refresh token itself.
- 3During a security audit you discover that a stolen refresh token can be reused within its validity window. What changes would you make to the rotation logic to mitigate this?
5-8 years experience
- 1Design a scalable refresh‑token rotation mechanism for a service handling millions of daily active users, ensuring low latency and minimal storage overhead.
- 2How would you handle token revocation and rotation when you have stateless microservices that cannot share a central database synchronously?
- 3Discuss how you would protect against replay attacks in a distributed environment where multiple instances may process the same refresh request.
8+ years experience
- 1Our platform is moving from a monolithic authentication service to a zero‑trust architecture with multiple independent services issuing JWTs. How would you evolve the refresh‑token rotation strategy to support this migration while preserving security?
- 2Consider a legacy system that only supports long‑lived refresh tokens. Propose a phased approach to introduce rotation without breaking existing clients.
Follow-up Questions
- What would you do if a refresh token is presented after it has already been rotated?
- How do you prevent race conditions when two requests try to rotate the same token?
- Can you explain how you would audit token usage for suspicious activity?