3.0.0: reuse_detection is silently inert when hash_tokens is enabled (spent registry keyed on the stored hash, lookup keyed on the raw token)

[sanchobouillant]

Version: gesdinet/jwt-refresh-token-bundle 3.0.0 · Symfony 8.1.5 · PHP 8.4/8.5 · Doctrine ORM 3.6 (Postgres) · lexik/jwt-authentication-bundle 3.2.0

Summary

With both hash_tokens.enabled: true and reuse_detection.enabled: true, replaying a spent single-use refresh token is rejected (401) but never revokes the family: the detection never fires, with no error and no log.

Cause (read in the source)

• AttachRefreshTokenOnSuccessListener.php:258 calls remember($refreshToken) with the model.
• CacheSpentRefreshTokenRegistry::remember() keys the entry on sha256($refreshToken->getRefreshToken()). When hash_tokens is on, getRefreshToken() returns the stored hash (as the listener itself notes around line 304: "a manager that hashes the token keeps the hash on the model"), so the key is sha256(hash).
• On replay, RefreshTokenAuthenticator.php:102 calls unknownTokenPresented($token) with the raw token from the request, and recall() looks up sha256(raw).
• sha256(hash) !== sha256(raw) → nothing is ever recalled.

Reproduction (deterministic — one key changed, everything else identical)

Config: single_use: true, single_use_ttl_update: true, reuse_detection: { enabled: true, cache: cache.app }, Doctrine storage.

1. login → RT1
2. refresh with RT1 → 200, RT2
3. refresh with RT1 again (replay) → 401 (expected, single use)
4. refresh with RT2 (valid, never used) →
   • hash_tokens.enabled: false → 401 — family revoked ✅
   • hash_tokens.enabled: true → 200 — family alive ❌ (detection inert)

Verified twice independently (author + reviewer) on the same code base.

Expected

Either the registry keys on the raw token on both sides (the raw value is available in the request when the token is spent), or the two options are declared mutually exclusive at configuration time (like cache_pool vs reuse_detection already is), so the failure is loud instead of silent.

Workaround we chose

Keep hash_tokens: true and set reuse_detection.enabled: false explicitly (with a comment) until fixed. Happy to test a patch.

[sanchobouillant]

Companion issue: #434 — enabling reuse_detection also fails container compilation in 3.0.0 (placeholder passed as a service id).

[twispr]

Confirmed on v3.0.0, and your analysis matches what we traced in the source:

• write side: AttachRefreshTokenOnSuccessListener re-reads the model through the manager, so with hash_tokens its getRefreshToken() is the stored sha256$<hex> form, and CacheSpentRefreshTokenRegistry::remember() keys the pool with a digest of that
• read side: RefreshTokenAuthenticator calls recall() with the raw token from the request. The two keys never match. So reuse detection never fires while both options are enabled

If it helps anyone, instead of disabling reuse_detection, we kept it working with a small decorator that recalls both forms (the sha256$ prefix mirrors HashedRefreshTokenManager, where it is private):

final class HashAwareSpentRefreshTokenRegistry implements SpentRefreshTokenRegistryInterface
{
    private const string HASH_PREFIX = 'sha256$';

    public function __construct(private readonly SpentRefreshTokenRegistryInterface $inner) {}

    public function remember(RefreshTokenInterface $refreshToken): void
    {
        $this->inner->remember($refreshToken);
    }

    public function recall(string $refreshToken): ?SpentRefreshToken
    {
        return $this->inner->recall($refreshToken)
            ?? $this->inner->recall(self::HASH_PREFIX.hash('sha256', $refreshToken));
    }
}

Registered as the gesdinet_jwt_refresh_token.spent_refresh_token_registry service decorating the original. With this in place, replaying a spent token revokes the family as documented.

For the bundle itself, hashing inside the registry consistently on both paths seems like the smallest fix. Failing that, making the two options mutually exclusive at config time would at least turn the silent failure into a loud one.