Refresh-token rotation under concurrent replay: 200 scheduled callers
A reproducible local test of one-use token families, revocation and expiry, with the exact limits of a single-process model.
A refresh credential is supposed to be consumed and rotated when it is used. What happens when two callers present it before the backend records the first rotation?
A small reference test harness was developed to expose this question in a controlled setting. Its public source is ZombieMutex Session Rotation. The implementation uses SHA-256 digests of high-entropy random token bytes and tracks active, consumed, expired and revoked state for one token family.
This is not a production session server, signed JWT issuer or example of working with real customer credentials.
Test setup
One local session family begins with a single valid refresh token. The test schedules 200 Promise callbacks, each attempting to rotate the same token.
The important assertion is simple:
Observed local outcomes
| Condition | Local test observation |
|---|---|
| 200 scheduled uses of one token | One successor accepted |
| Reuse of consumed token | Rejected as replay |
| Explicit family revocation | Blocks active and previously used credentials |
| Expired family token | Rotation denied |
| Duplicate family creation | Rejected |
Five repository tests passed under Node.js 24.21 on macOS. These are reproducible logical outcomes, not evidence of cross-region atomicity or hardened production account recovery.
The trust boundary
The code runs within one process. Synchronous consume-and-replace operations are serialized by the JavaScript runtime, so the test is intentionally incapable of reproducing a database-level lost-update race across two independent server processes. Treat its result as an assertion about a local state machine, not a service-level availability or security guarantee.
Real production token families require durable atomic updates, expiration and key lifecycle handling, issuer/audience validation where relevant, explicit theft-detection policy, service-wide revocation, and protected recovery flows. Do not log raw refresh tokens or accept client-reported session state as authorization.
The interactive session recovery lab lets a reader share a specific synthetic event sequence. The deeper session state-machine guide covers the recovery bypasses a simple rotate function does not address.
Provenance: A new AI-assisted reference project with actual local tests. It does not claim to represent an existing real-world account service, security certification or personal employment accomplishment.
Continue exploring
Related technical notes with overlapping topics.