Test jti reuse rejected after cache flood

[anthonydahanne]

Test-only; no production code changes.

Adds a regression test to DPoPProofJwtDecoderFactoryTests for the replay cache under flooding.

The existing tests cover a plain single-proof replay, but not the case where the cache is filled past its size limit before the replay.
The new test floods with proofs signed by other keys; split across two so neither hits the per-key request limit.
Then confirms a fresh proof from the original key is still accepted while a replayed one is rejected, so only replay detection (not the per-key throttle) can account for the rejection.

[anthonydahanne]

@jgrandja thank you for re considering; I really appreciate it 🙏 .

I have re-submitted title / description / content - hopefully it's a valuable addition to the spring-security tests.

[jgrandja]

Thank you @anthonydahanne and apologies for the confusion.

I will get to this soon. Thanks.

[jgrandja]

@anthonydahanne I took a look at the test and I'm not understanding exactly what the difference is compared to decodeWhenJtiAlreadyUsedThenThrowBadJwtException()? The existing test demonstrates replay detection.

The test in this PR also demonstrates replay detection and it additionally floods the cache but I don't see the value of it? It floods the cache with 1200 entries - 600 entries per key bucket so within the per key limit of 1000. The default max entries allowed is 100,000 and also within the limit given 1200 entries plus 1 entry of the original proof.

Can you provide some clarification on the main goal of the test? Maybe I'm missing something?

[anthonydahanne]

Hello @jgrandja !
Thanks for having a look!

The distinction I was aiming for is that decodeWhenJtiAlreadyUsedThenThrowBadJwtException() checks an immediate duplicate while the jti is still present.

The former implementation had JtiCache.MAX_SIZE = 1000 and used removeEldestEntry, so that existing test still passed even though more than 1,000 unrelated proofs could evict the original jti and allow its replay.
That is why I placed 1,200 proofs between the original use and replay, split across two keys to stay below the new per-key limit.

That said, you are right about the test as currently written: it injects the new InMemoryCache with its default maximum size of 100,000, so those 1,200 entries never exercise the current cache-full behavior.
In this setup, the original jti simply remains cached, making the final assertion effectively equivalent to the existing replay test.

I suggest to you that either:

• we drop this test and PR, since as you noticed it's not adding value in this form, I'm sorry about that, I kept in my mind the maxSize set to 1000...
• I rework it to make it up-to-date and relevant: as in I use a deliberately small configured maxSize, fill it with unexpired entries, and verify that overflow is rejected rather than evicting an existing jti; verifying explicitly that the original entry remains to confirm that version genuinely distinguishes retention from a plain "cache full" rejection.

[jgrandja]

@anthonydahanne Can you please rework the test and configure maxSize and maxRequestsPerKey to a smaller size and test the cache full rejection and replay detection. Thanks!

[anthonydahanne]

@jgrandja I updated the test with smaller sizes and replay detection and rejections
let me know if that's valuable!
Thanks!