OAuth 2.0 Refresh Token Rotation and Concurrent Request Limits

Question

Implementing Refresh Token Rotation is a common security measure to mitigate the risk of token theft by issuing a new refresh token with every access token renewal. However, this mechanism introduces complexity when handling concurrent requests in high-latency environments or distributed systems.

When multiple asynchronous requests attempt to use the same refresh token simultaneously, the authorization server may trigger reuse detection. According to standard security patterns, reuse detection typically results in the immediate revocation of the entire token family to protect the user session.

There is uncertainty regarding the optimal configuration for a grace period that allows for network retry overlap without compromising the security benefits of rotation.

What are the industry-standard limits for the reuse detection grace period to prevent accidental session revocation during concurrent refreshes?
  How can a system distinguish between a legitimate race condition and a malicious token reuse attempt during this window?

Wasi · Answer

Handling Concurrent Refresh Requests
Industry-standard grace periods for refresh token reuse detection typically range from 10 to 60 seconds. This window allows for network latency, client-side retries, and race conditions in distributed systems without significantly expanding the window of opportunity for an attacker.

Implementation Logic
To prevent accidental session revocation while maintaining security, the authorization server should transition from a strict "one-time use" model to a "time-bound validity" model during the rotation event:

Rotation Event: When a refresh token is exchanged, the server marks the old token as "rotated" and records the timestamp of the exchange.
  Grace Window: If the same token is presented again within the defined grace period (e.g., 30 seconds), the server returns the already issued new token pair rather than triggering reuse detection.
  Reuse Detection: If the token is presented after the grace period has expired, it is flagged as a malicious reuse attempt, and the entire token family is revoked.

Distinguishing Race Conditions from Attacks
A system distinguishes legitimate concurrency from theft by analyzing the timing and the requested outcome:

Scenario
      Behavior
      System Response

Race Condition
      Multiple requests arrive within milliseconds or seconds of each other.
      Return the same new token pair to all concurrent requests within the grace window.

Token Theft
      A token is reused significantly after the first rotation occurred.
      Immediate revocation of all tokens associated with that session (Family Revocation).

Verification Steps
To verify your grace period configuration, use a load-testing tool (such as k6 or JMeter) to execute the following scoped tests:

Concurrent Burst: Send 5 simultaneous refresh requests using the same token. The session should remain active, and all requests should ideally receive the same new token.
  Delayed Reuse: Rotate a token, wait for the grace period to expire (e.g., 61 seconds), then attempt to use the old token. The system must revoke the entire session.

Diagnostic Requirement: To refine this recommendation, please specify if your authorization server uses a distributed cache (e.g., Redis) or a relational database for token state, as this affects the atomicity of the reuse detection check.

OAuth 2.0 Refresh Token Rotation and Concurrent Request Limits

1 answer

Handling Concurrent Refresh Requests

Implementation Logic

Distinguishing Race Conditions from Attacks

Verification Steps

Your perspective belongs here.

0 question comments

Scenario	Behavior	System Response
Race Condition	Multiple requests arrive within milliseconds or seconds of each other.	Return the same new token pair to all concurrent requests within the grace window.
Token Theft	A token is reused significantly after the first rotation occurred.	Immediate revocation of all tokens associated with that session (Family Revocation).