The detector is two branches of one function. The sample `rotateRefreshToken` checks `record.status === 'spent'`, then checks `family.status !== 'active'`, and throws `invalid_grant` either way [11]. The client learns nothing from the difference. The difference lives in the audit write, which carries a type of `refresh_token_reuse` plus the subject and the family id [17]. That split is correct engineering: the error code is a channel an attacker can also read, and the forensics belong somewhere only you can read [11][19].
The token value itself is 32 random bytes rendered base64url [12]. That is 256 bits of entropy in 43 characters unpadded [14]. It is opaque, so the server resolves it by value; a JWT-encoded refresh token is resolved by its `jti` claim instead [5]. Either way the server has to hold a record for every value it has ever issued in that family, because the spent marker is the recognizer [4].
So price the storage honestly. Rows retained per family equal rotations plus one [15]. Pruning is only safe when the family itself dies, since a deleted spent row is a replay you can no longer identify [4]. Delete-on-rotate is the cheapest possible way to forget the single thing you needed to remember.
There is a second cost, and the pseudocode shows it plainly. The reuse branch keys on the status of the presented token, not on which party presented it [16]. The walkthrough's claim is that a spent token can only reappear if two parties held it at once [7]. Grant that, and the response is still to revoke the whole family, including the active token the legitimate client is holding, forcing a full re-authentication [8]. If any benign path in your client can present a value it already exchanged, the penalty falls on the real user's session. Test that path before you ship the revoke-all default.
What transfers from this piece is not the vendor shape. It is the state requirement. Rotation on its own only shrinks the replay window, because the server cannot separate the attacker's exchange from the app's [2], and a static token leaves a credential valid for a TTL the author puts at 30 to 90 days with no signal to the owner [1]. The two lookups that produce the signal are exactly what a naive implementation skips when it deletes old tokens rather than marking them spent [13].
That has a scheduling consequence teams underrate. Detection is prospective only. Change the write path today and you gain lineage for families opened after the change; the sessions already running were never recorded, so their spent values are gone [4][13]. My read, in a context where refresh tokens live on mobile clients: the family record is worth its row count, and the revoke-all step is worth its support tickets, because rejecting the reused token alone leaves a live credential in play [10]. If your refresh tokens are short-lived and confined to a first-party web session, the arithmetic may land elsewhere, and I would want to see the forced re-auth rate before defending the default.
