-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
JWKS Uri containing an encryption key (besides signature keys) will fail io.jwt.decode_verify #4699
Comments
Thanks for bringing that up! We've been discussing a revamp of some of the playground before, since there are a few controls to expose: strict mode, coverage, strict builtin errors; and adding further buttons makes the UI too convoluted, so some sort of ⚙️-menu with all the knobs would be useful...hoping this may happen sometime 🤞 However, defaulting to strict builtin errors is a more debatable thing -- it's not the evaluation mode used by the server, or Thanks for providing that workaround! ✨ A tiny nitpick, if you pass jwks := jwks_request("YOUR_JWKS_URI").body
filtered_jwks := [ key |
some key in jwks.keys # assuming `import future.keywords.in`
key.use == "sig"
] |
Yeah, tbh I'm not sure about the details of how it behaves differently if you provide I totally get that it might get convoluted with more buttons. While it would have taken more time, eventually I would have tried all the options from a ⚙️ menu I guess, so it would definitely be an improvement :-). Thanks for the caching hint! Is there a way to also cache the filtered jwks? I also like the syntax you provided, so I'll use it for our code as well :-). EDIT: I took the |
Nope you can't cache the intermediate result there... but having less to do when re-calculating it for evert policy eval will be better 😅 And yes, updating those docs would be a good call. Of course you could use Speaking if more hassle than it's worth, I've often found that it's more straightforward to use the JWT built-in functions other than |
Just an update for anybody reading this thread in the future, trying what I tried: The parameter to force json evaluation is named |
Ugh sorry about that. 🤦 |
No problem, let's simply say that there is more room for better error reporting also in that area :-). Still, thanks a lot for helping me over here, it brought it forward and I learned a few new things :-) |
Glad you're unstuck. However, there are a few things to improve mentioned in your original issue, and the comments. So let's keep this open for tracking. |
Thanks for reporting this @lenalebt! We should indeed be smarter about signature verification. In addition to not fail when encountering keys of unknown type, the verification could be improved by:
|
Additionally, improve the JWT verification process when a JWKS is provided: * If `kid` is present in JWT header, and exists in JWKS — verify using that key only. * If `kid` not present in JWT header, try verification only using keys matching the `alg` provided in the JWT header (mandatory claim). Fixes open-policy-agent#4699 Signed-off-by: Anders Eknert <anders@eknert.com>
Additionally, improve the JWT verification process when a JWKS is provided: * If `kid` is present in JWT header, and exists in JWKS — verify using that key only. * If `kid` not present in JWT header, try verification only using keys matching the `alg` provided in the JWT header (mandatory claim). Fixes #4699 Signed-off-by: Anders Eknert <anders@eknert.com>
Thanks for the changes, I think this will really make things easier to use 😄 ! |
Short description
We use Keycloak, and it was configured to also have an encryption key exposed on the JWKS URI, using an algorithm that OPA does not support. OPA fails, but you cannot easily see that if you do not use the
--strict-builtin-errors
flag, which is not set on the Rego playground at https://play.openpolicyagent.org/.OPA should ignore keys it does not support instead of failing, offer options for filtering, or better document that behaviour. In the above case, it's enough to only feed signature keys to
io.jwt.decode_verify
.Steps To Reproduce
Use a JWKS like this:
Call
io.jwt.decode_verify
as described in the example from https://www.openpolicyagent.org/docs/v0.39.0/policy-reference/#using-jwks :-> OPA fails to validate the token, even if it is signed with the key OPA supports.
Expected behavior
--strict-builtin-errors
by default (any reason not to?), or at least offer an option to enable thatWe implemented this manually via this code (for others to use):
Additional context
We did not configure our keycloak to explicitly contain an encryption key in the JWKS endpoint - we're using a SaaS provider, and that was the default configuration over there.
The text was updated successfully, but these errors were encountered: