Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
johakoch opened this issue Feb 5, 2024 · 4 comments
Open

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

johakoch opened this issue Feb 5, 2024 · 4 comments

Comments

@johakoch
Copy link
Collaborator

johakoch commented Feb 5, 2024

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
Copy link
Contributor

filex commented Feb 5, 2024

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

@johakoch
Copy link
Collaborator Author

johakoch commented Feb 5, 2024

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
Copy link
Contributor

filex commented Feb 24, 2024

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
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants