search

coupergateway / couper

Couper is a lightweight API gateway designed to support developers in building and operating API-driven Web projects
https://couper.io
MIT License
84 stars 15 forks source link

Go back once to JWKS resource if kid is unknown #801

Open johakoch opened 7 months ago

johakoch commented 7 months ago

From https://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys:

The signer can begin using a new key at its discretion and signals the change to the verifier using the kid value. The verifier knows to go back to the jwks_uri location to re-retrieve the keys when it sees an unfamiliar kid value.

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.

filex commented 7 months ago

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

johakoch commented 7 months ago

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 commented 6 months ago

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 commented 6 months ago

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.