High SeverityConcurrencySecurity

The False Alarm Rotation Race

1.The Symptom (The Chaos)

The backend cleanly rotated the user's security tokens, but a rapid network retry instantly treated the old token as a malicious hack, destroying the session and forcefully logging out a legitimate user.

2.The Trigger Condition

A client device suffers a brief packet drop during a refresh request, causing its HTTP client to automatically fire an immediate, identical retry request to the server.

3.The Catch (Why it broke)

We treated Token Rotation as a purely sequential, instantaneous operation, assuming the client would always receive and store the new token pair before any subsequent request could hit our API.

4.Architectural Trade-offs

To resolve this, we introduce a brief memory-cached grace window for recently rotated keys. This completely eliminates accidental session lockouts for real users, but requires a microscopic 5-second window where a stolen token could theoretically be reused before the system flags it as a breach.

JwtUtil.java

[Vulnerable Target View]

// VULNERABLE: We immediately invalidate and flag old refresh tokens.
// If a rapid network retry arrives before the client saves the new tokens,
// the server assumes a replay attack and violently destroys the session.
public TokenPair refresh(String oldRefreshToken) {
    if (isTokenUsed(oldRefreshToken)) {
        revokeAllUserSessions(oldRefreshToken); // Force Logout!
        throw new SecurityException("Token reuse detected!");
    }
    markTokenAsUsed(oldRefreshToken);
    return generateNewTokenPair();
}