-
-
Notifications
You must be signed in to change notification settings - Fork 361
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
feat: improved JWT Authorizer JWKs fetching #726
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Just some minor details here :)
Also, sorry for taking so long to review. I just had time to work on the backlog...down to only 12 more GH notifications (from 500 😰 )
credentials/fetcher_default.go
Outdated
@@ -124,19 +128,21 @@ func (s *FetcherDefault) fetchParallel(ctx context.Context, locations []url.URL) | |||
select { | |||
case <-ctx.Done(): | |||
s.l.Errorf("Ignoring JSON Web Keys from at least one URI because the request timed out waiting for a response.") | |||
return fetchResult{true} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe return an error here instead? And then we check for errors in the caller code? That would be a bit more idiomatic go code :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the honest feedback, I really appreciate comments like this - I am not that proficient with Go yet :)
Changed to return error
, is now ok - or should I even improve the implementation with a custom error?
No worries, I understood already from my first Oathkeeper PR that you're quite a busy man :)) |
…ed error propagation)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, thank you for your contribution! :))
Related issue
#203
@aeneasr
Proposed changes
The current implementation is not suitable for deployments in which low response times are required. With this PR I am improving the current implementation with the following changes:
FetcherDefault
fetches new JWKS and the request takes more then allowed, it will use "stale" JWKs for JWT validation. The refresh request will still continue and if successful, it will refresh the cached JWK for the "next" request.FetcherDefault
already accepts configuration for JWK cache TTL and max await for the refresh(and init!) JWK requests, the problem was that the end user could not change these values. This PR enables the user to change these values with 2 new configs:authenticators.jwt.config.jwks_max_wait
andauthenticators.jwt.config.jwks_ttl
.Checklist
vulnerability. If this pull request addresses a security. vulnerability, I
confirm that I got green light (please contact
[email protected]) from the maintainers to push
the changes.
works.
Further comments
I am aware that adding 2 more configuration keys makes stuff a little bit more complex, but I am certain this will help out quite a bit of users down the road. Schemas + docs + reference config updated.