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
{{ message }}
This repository has been archived by the owner on Apr 1, 2024. It is now read-only.
I searched in the issues and found nothing similar.
Motivation
When an unexpected signing key rotation occurs, the OpenID Connect Authentication Provider will not discover the new signing key and invalidate the old signing key until its cache expires. The current solution is to restart each broker, proxy, websocket proxy, and function worker. That process creates unnecessary downtime. Ideally, we can find a solution that maximizes control of the cache without introducing unnecessary service disruptions.
Solution
One solution could be to create a way to invalidate an AuthenticationProvider's cache. It would seem like we'd also need a way to force all connections to be re-authenticated. Perhaps that is best achieved by disconnecting all clients or by some other means.
Alternatives
No response
Anything else?
It might also make sense to update the Open ID Connect Authentication Provider's implementation to follow the cache control headers returned by the identity provider.
Are you willing to submit a PR?
I'm willing to submit a PR!
The text was updated successfully, but these errors were encountered:
Original Issue: apache#20108
Search before asking
Motivation
When an unexpected signing key rotation occurs, the OpenID Connect Authentication Provider will not discover the new signing key and invalidate the old signing key until its cache expires. The current solution is to restart each broker, proxy, websocket proxy, and function worker. That process creates unnecessary downtime. Ideally, we can find a solution that maximizes control of the cache without introducing unnecessary service disruptions.
Solution
One solution could be to create a way to invalidate an
AuthenticationProvider
's cache. It would seem like we'd also need a way to force all connections to be re-authenticated. Perhaps that is best achieved by disconnecting all clients or by some other means.Alternatives
No response
Anything else?
It might also make sense to update the Open ID Connect Authentication Provider's implementation to follow the cache control headers returned by the identity provider.
Are you willing to submit a PR?
The text was updated successfully, but these errors were encountered: