Refactor JTI validation from white-list to black-list

[paullatzelsperger]

Feature Request

the current JTI validation is based on a white-list model: the token creator puts the JTI in a database, and the verifier only accepts the JTI if it is found in that database, removing it immediately after use.

This should be changed such that the verifier checks the database if a JTI string is present, rejecting the token if present. If the JTI was not found, the verifier accepts the token but records the JTI claim in the database, together with a timestamp.

JTI claims that were found in the database, but whose age exceeds the maximum duration, are considered valid too.

A reaper thread should clean up expired JTI claims periodically to avoid growing DB tables.

Which Areas Would Be Affected?

e.g., DPF, CI, build, transfer, etc.

Why Is the Feature Desired?

avoid coupling between the creator and the verifier of a token.

Who will sponsor this feature?

Please @-mention the committer that will sponsor your feature.

Solution Proposal

• in EmbeddedSecureTokenService: remove the creation of the JtiValidationEntry
• in JtiValidationRule: the rule fails if the JtiValidationEntry is found in the database and has not yet exceeded it maximum lifetime.
• in IdentityHub's DefaultServicesExtension: spawn a periodic thread to clean up expired JtiValidationEntries