You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Checklist
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.
The text was updated successfully, but these errors were encountered: