In order to guard against memory exhaustion attacks, a server that is tracking jti values should reject DPoP proof JWTs with unnecessarily large jti values or store only a hash thereof.
Currently our JWTIdentifierClaimsValidator simply stores/checks the raw jti value against the ReplayCache. It should be improved as suggested by the quote above.
After discussing with @Philip Smart , we agreed that we want to add a Function<String,String>-hook to JWTIdentifierClaimsValidator to optionally calculate the replay cache key value from the jti.
The commit 18bf0d16ad4055986ee3221815caec45c622489a also includes a function (CalculateSha256DigestForLongKeyFunction) that calculates SHA-256 hex string for the inputs that are longer than 64 characters.
The section 11.1 of the DPoP RFC contains the following paragraph:
Currently our
JWTIdentifierClaimsValidatorsimply stores/checks the rawjtivalue against theReplayCache. It should be improved as suggested by the quote above.