Description
Checklist
- I have looked into the Readme and Examples, 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 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.
Describe the problem you'd like to have solved
In light of the recent Auth0/Cloudflare outage, we discovered that this library hard evicts the underlying JWKS after the maxCacheAge expires. Unfortunately, if this occurs at the same time as, say, Auth0 and its JWKS are unavailable, then there is no graceful degradation of service. Instead, the service immediately begins rejecting tokens. This results in total service unavailability even if the clients accessing the service have tokens that would continue to be valid for many hours.
With the default 10 minute max cache age, that means services can, on average, only tolerate 5 minutes of downtime before becoming unavailable in the current state.
Describe the ideal solution
In the face of errors attempting to refresh a JWKS, the library should be able to gracefully continue and use a stale JWKS during the unavailability of the remote source.
Alternatives and current workarounds
We're looking at writing a wrapper around this library to be able to provide this graceful fallback, but it would be ideal if this mechanism were done inside the library instead.
Additional context
Notably, some libraries in other languages already work to provide a graceful fallback mechanism in the face of a network partition or unavailability of the source.
One such example is neoeinstein/aliri, which ensures that JWKS source unavailability does not result in total service unavailability.