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

Consolidate the way JWK sets are loaded #82

Closed
sberyozkin opened this issue Jun 21, 2019 · 1 comment
Closed

Consolidate the way JWK sets are loaded #82

sberyozkin opened this issue Jun 21, 2019 · 1 comment
Assignees

Comments

@sberyozkin
Copy link
Contributor

sberyozkin commented Jun 21, 2019

At the moment the JWT sets are dealt with in two different places. First mp.jwt.publickey.location is checked if it points to a JWK set resource in KeyLocationResolver. Next if an internal followMpJwt11Rules is set then it is assumed that instead of mp.jwt.publickey.location jwksUri was set and the keys are loaded not in the resolver but in the parser. So we have two ways to point to JWKs, only one of them is used in smallrye-jwt while the jwksUri path is used via a followMpJwt11Rules diversion from Thorntail.

This really needs to change and followMpJwt11Rules needs to go as it is confusing (and will become more so when we move to newer versions of MP JWT). Instead KeyLocationResolver should keep all the code for loading the keys, for example, it can check if the location starts from https etc.
JWTAuthContextInfo jwksUri should also be renamed to publicKeyLocation or similar, otherwise at the moment, if is actually used to load PEM keys as well, it is initialized with mp.jwt.publickey.location which adds the extra confusion.

@sberyozkin
Copy link
Contributor Author

Good opportunity to fix it now given that we plan to release 2.0.0

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

1 participant