[X] 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.
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?