Only accept private JWTs for client authentication if their lifetime is shorter than some time t ("fresh tokens")

[Mushroomator]

I want to use private JWT Bearer authentication for client authentication. I have hooked up an IDistributedCache implementation to detect replay attacks. However, currently that cache only stores JTIs fixed up to 5 minutes.

        if (await _replayCache.ExistsAsync(Purpose, jti, ct))
        {
            _logger.LogError("jti is found in replay cache. Possible replay attack.");
            return fail;
        }
        else
        {
            await _replayCache.AddAsync(Purpose, jti, exp.AddMinutes(5), ct);
        }

That is also fine, since obviously not all JTIs can/ should be stored indefinitely. But that means if somebody were to create a JWT with a lifetime of 10 minutes, the token would be stolen and replayed after 5 minutes have elapsed a replay attack would still be possible.

In order to prevent that, the replay cache expiration could be aligned with the token lifetime. So if the cache TTL is 5 minutes, a token which has a longer lifetime than 5mins would not be accepted. So basically a token would only be accpected if the following holds true:

exp - iat <= cacheTtl + clock skew

While I could probably work with the default currently, preferrably cache TTL for JWT Bearer auth and clock skew could be configurable as well globally or per-client (as is the case with other options). Maybe there would even be an option for StrictReplayDetection = true/ false so it could be turned on or off.

I know I could implement this already by decorating the default ClientSecretValidator implementation, accessing the ParsedSecret inside it, re-read the JWT token (as the parsed JsonWebToken instance is unfortunately not available in the context) to get the claim values, add client properties for clock skew etc. and fail the secret validation if my additional check fails. Still, I think this should be a common enough security issue that it would make sense to include it in the product directly.

[wcabus]

However, currently that cache only stores JTIs fixed up to 5 minutes.

The replay cache stores the JTI using an absolute expiration timestamp based on the private key JWT's exp claim value increased with 5 minutes to account for clock skew.

For example, given a token with the following payload:

{
    "iss": "interactive.confidential.jwt",
    "sub": "interactive.confidential.jwt",
    "aud": "https://demo.duendesoftware.com/connect/token",
    "jti": "ffe2586bd6ce435e80d288ac4a5bfa98",
    "iat": 1781262757,
    "exp": 1781266357
}

The iat claim value resembles 12/06/2026, 11:12:37 UTC and exp is one hour later at 12/06/2026, 12:12:37 UTC. The JTI value will be stored in the replay cache until 12/06/2026, 12:17:37 UTC.

[Mushroomator]

You're absolutely right. Even had the relevant part in the code snippet in my OP. Must have had the wrong glasses on that day... 🤦🏼 Apologies, this eliminates replay attacks of course and therefore there is no bigger security issue.

I would probably still personally like to enforce short lifetimes, but that is of course much less of an issue (as hopefully nobody generates tokens in advance and keeps them around for later use). Nevertheless would be appreciated if there was a MaxClientAuthenticationTokenLifetime or alike config value per client/ globally.

[wcabus]

No worries about the confusion there! I'll relay the question to configure a per-client or global max lifetime to the engineering team 🙂.

We may however decide to simply reject the private key JWT when configuring a global or per-client setting (e.g. MaxPrivateKeyJwtLifetime) if the lifetime of the JWT exceeds that value, rather than shortening the replace cache duration time for that JWT.

[Mushroomator]

Absolutely, that is exactly what I meant. Thanks :) And sorry again for the confusion ;)