Open johakoch opened 7 months ago
This is a source of DoS. An attacker could send random kid
values forcing upstream JWKS refresh attempts with every token.
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.
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.
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.
From https://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys:
IdPs may add a public key to JWKS and use the corresponding private key right away to sign JWT.
Couper will currently not recognize this change (until it syncs JWKS) and throw an error, because it can't find a key for the new
kid
in its cached JWKS.So instead of throwing an error, Couper should first sync JWKS, then try again to find the key.
This may also apply to the jwt access control.