You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Whereby both the staging and testing JWKS endpoints include a shared kid value (e.g. key1).
With this configuration, the auth plugin will only validate against the first in the list (in this case, the testing jwks). It may be necessary to support multiple of the same kid in cases of staging/testing environments, where there's a fallback kid for both that shares the same identifier.
To Reproduce
Given this token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImtleTEifQ.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyMzkwMjIyLCJhdWQiOiJ0ZXN0aW5nIn0.DVPtUcLYlgEFE2OjLEJ6LQp6-Sflm9rJKHUqXCUFV8g
You'll first see the token failing- the last entry takes precedence. Swapping the two config options results in it working.
Expected behavior
The kid is not only checked, but the right JWKS is used based on the aud, or the token is checked against all possible matches vs. the first one.
Desktop (please complete the following information):
OS: macOS
Version [e.g. 22]: 1.15.1
The text was updated successfully, but these errors were encountered:
Fix#3017
in some cases, multiple keys can match what a JWT asks (algorithm and
optional kid). Previously, we scored each possible match and only took
the one with the highest score. But even then, we can have multiple keys
with the same score (example: colliding kid between multiple JWKS in
tests).
This changes the behaviour to:
- return a list of matching key instead of the one with the highest
score
- try them one by one until the JWT is validated, or return an error
- if some keys were found with the highest possible score (matching alg,
kid is present and matching too), then we only test those ones
Co-authored-by: Coenen Benjamin <benjamin.coenen@hotmail.com>
Describe the bug
Given a configuration that looks like:
Whereby both the staging and testing JWKS endpoints include a shared
kid
value (e.g.key1
).With this configuration, the auth plugin will only validate against the first in the list (in this case, the testing jwks). It may be necessary to support multiple of the same
kid
in cases of staging/testing environments, where there's a fallbackkid
for both that shares the same identifier.To Reproduce
Given this token:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImtleTEifQ.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyMzkwMjIyLCJhdWQiOiJ0ZXN0aW5nIn0.DVPtUcLYlgEFE2OjLEJ6LQp6-Sflm9rJKHUqXCUFV8g
And these JWKS files:
Testing JWKS
Staging JWKS
And lastly, this config:
You'll first see the token failing- the last entry takes precedence. Swapping the two config options results in it working.
Expected behavior
The
kid
is not only checked, but the right JWKS is used based on theaud
, or the token is checked against all possible matches vs. the first one.Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: