Based on https://github.com/ramosbugs/openidconnect-rs/issues/152 and some discussions with @partim , it seems like the OpenID connect client does not automatically rediscover anything, leading to login loops when e.g. the JWKs are rolled (as the signature can no longer be verified).
This PR adds an explicit lifetime to the connection, and if the connection has existed for more than 60 seconds, it will initialise a new client. This is a tradeoff between doing rediscovery on every request (so requesting the /.well-known/openid-configuration endpoint, the jwk_uri inside that, and then the endpoint for the userinfo), which might slow things down on grouped requests, whilst also reasonably quickly learning about configuration changes.
The 60 seconds is arbitrary, and it might be nicer to make this configurable or document it somehow. Even nicer would be to honour the cache lifetimes of the HTTP responses, but I am not sure whether that is worth the effort.
Based on https://github.com/ramosbugs/openidconnect-rs/issues/152 and some discussions with @partim , it seems like the OpenID connect client does not automatically rediscover anything, leading to login loops when e.g. the JWKs are rolled (as the signature can no longer be verified).
This PR adds an explicit lifetime to the connection, and if the connection has existed for more than 60 seconds, it will initialise a new client. This is a tradeoff between doing rediscovery on every request (so requesting the /.well-known/openid-configuration endpoint, the jwk_uri inside that, and then the endpoint for the userinfo), which might slow things down on grouped requests, whilst also reasonably quickly learning about configuration changes.
The 60 seconds is arbitrary, and it might be nicer to make this configurable or document it somehow. Even nicer would be to honour the cache lifetimes of the HTTP responses, but I am not sure whether that is worth the effort.