Go back once to JWKS resource if kid is unknown

[johakoch]

Go back once to JWKS resource if kid is unknown

[filex]

This is a source of DoS. An attacker could send random kid values forcing upstream JWKS refresh attempts with every token.

[johakoch]

This is a source of DoS. An attacker could send random kid values forcing upstream JWKS refresh attempts with every token.

In the jwt access control, yes.

[filex]

The lookup of unknown keys would allow to cache a JWKS response forever (which ends with the next restart). We could change the default TTL for JWKS to forever (or a much longer value than one hour) or even remove the possibility to define the TTL completely.

But in case an unknown KID is received in a token, the refresh must be synchronous and we have to hold the request until ready.

A short TTL would allow to retrieve new keys in the background without interrupting traffic - but obviously it depends on the implementation of the signer if keys are ever published well before use.

[johakoch]

https://support.okta.com/help/s/article/Access-Token-validation-failure-due-to-kid-mismatch?language=en_US:

Clients that cache keys should periodically check the JWKS for updated signing keys. Okta recommends a blended approach of regularly caching keys for performance and just-in-time checking by retrieving keys dynamically from the keys endpoint if the key read from the cache fails signature validation.