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

Race condition in JWK Caching Provider implementation? #288

Open
6 tasks done
jofleck opened this issue Oct 17, 2024 · 1 comment
Open
6 tasks done

Race condition in JWK Caching Provider implementation? #288

jofleck opened this issue Oct 17, 2024 · 1 comment
Labels
bug This issue reports a suspect bug or issue with the SDK itself

Comments

@jofleck
Copy link

jofleck commented Oct 17, 2024

Checklist

  • I have looked into the README and have not found a suitable solution or answer.
  • I have looked into the documentation and have not found a suitable solution or answer.
  • I have searched the issues and have not found a suitable solution or answer.
  • I have upgraded to the latest version of this SDK and the issue still persists.
  • I have searched the Auth0 Community forums and have not found a suitable solution or answer.
  • I agree to the terms within the Auth0 Code of Conduct.

Description

It seems like this library suffers a small race condition, when an IDP uses rolling keys. Under circumstances the validation of an JWT/JWK fails the first time.

Reproduction

  1. Use a JWKS Caching Provider with an OIDC conformant IDP
  2. Validate a JWT with this library and with a valid JWK -> works fine
  3. Wait until the IDP invalidates the current JWK
  4. Validate another JWT with the new JWK --> May fail with the error that the JWK type is not supported

Go JWT Middleware version

2.2.1

Go version

1.23

@jofleck jofleck added the bug This issue reports a suspect bug or issue with the SDK itself label Oct 17, 2024
@jofleck
Copy link
Author

jofleck commented Oct 17, 2024

The commit history of the caching function says that refreshing in the "background" is done intentionally rather than blocking until the keys are refreshed. But this can lead to the misbehavior I mentioned before :)

func (c *CachingProvider) KeyFunc(ctx context.Context) (interface{}, error) {

Maybe we can let the developers decide if the key refreshing should be done blocking or non-blocking?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue reports a suspect bug or issue with the SDK itself
Projects
None yet
Development

No branches or pull requests

1 participant