[Security]: Refresh token rotation has no reuse-detection grace window, causing concurrent refreshes to lock users out

[Srejoye]

Bug Description

refreshToken (backend/controllers/authController.js) validates the incoming refresh token against the current stored hash, then unconditionally overwrites user.refreshTokenHash with a newly rotated hash. There is no optimistic concurrency check (no compare-and-swap) tying the write to the specific old hash value that was validated, so concurrent refresh calls using the same token interfere with each other.

Steps to Reproduce

1. Log in and obtain a valid refreshToken.
2. Fire two concurrent POST requests to /api/auth/refresh using the same refreshToken (e.g. simulating multiple tabs or a double-fired axios interceptor).
3. Attempt to use both returned refreshTokens.

Expected Behavior

Concurrent legitimate refresh attempts using the same valid token should be handled gracefully (e.g. one succeeds cleanly, or both receive a consistent, valid rotated token), without forcing an unrelated re-login, and any true token-reuse-after-rotation should be distinguishable and trigger revocation.

Actual Behavior

Both requests pass bcrypt.compare against the same pre-rotation hash, then both rewrite refreshTokenHash — whichever save() lands last wins, silently invalidating the other request's newly issued refresh token. The losing client is forced into a full re-login with no distinct error from an actual stolen-token scenario.

Severity

Critical

Screenshots / Screen Recording

No response

Browser

No response

Operating System

No response

Additional Context

No response

[Srejoye]

Technical understanding: refresh-token rotation is implemented as an unguarded read-modify-write against a single mutable field (refreshTokenHash) with no optimistic concurrency control (no version check, no compare-and-swap on the old hash value at update time), so concurrent legitimate refresh calls interfere with each other rather than being serialized or de-duplicated.

Affected: backend/controllers/authController.js (refreshToken), backend/models/User.js (refreshTokenHash/refreshTokenExpiresAt fields).

Proposed fix approach: replace the read-then-save pattern with an atomic findOneAndUpdate({_id: decoded.id, refreshTokenHash: <old hash lookup key or a stored token id>}, {$set: {refreshTokenHash: newHash, ...}}) so rotation only succeeds against the exact previous token, and a losing concurrent request gets a clean "already rotated" response distinguishable from actual token theft. Consider introducing a short reuse grace period (e.g. accept the immediately-prior token for a few seconds to absorb legitimate double-fire race conditions) alongside real reuse-detection that revokes all sessions when an old, already-rotated token is replayed after the grace window.

Regression tests: fire two concurrent refresh requests with the same valid refresh token and assert exactly one succeeds and the failure mode is distinguishable from a stolen-token rejection; verify normal sequential refresh still works and old tokens are rejected post-rotation.

Requesting assignment for GSSoC'26.