Race condition in JWK Caching Provider implementation?

[jofleck]

Checklist

• [X] I have looked into the README and have not found a suitable solution or answer.
• [X] I have looked into the documentation and have not found a suitable solution or answer.
• [X] I have searched the issues and have not found a suitable solution or answer.
• [X] I have upgraded to the latest version of this SDK and the issue still persists.
• [X] I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• [X] 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]

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 :)

https://github.com/auth0/go-jwt-middleware/blob/f5f0a00e029f875cc2c23584955877f4cae13c57/jwks/provider.go#L136

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