OpenID-Connect stops working after Microsoft signing key rollover

[plevan74]

We have our instance of Krill configured for OpenID-Connect with login.microsoftonline.com.

Every now and then we get in a situation where authentication with login.microsoftonline.com completes but Krill sends us back to the login page. We get log entries like the following one when that happens:

Sep 11 11:24:00 SERVERNAME krill[2943457]: 2024-09-11 11:24:00 [WARN] [krill::daemon::auth::providers::openid_connect::provider] OpenID Connect: ID token verification failed: Signature verification failed [additional info: caused by: Signature verification failed, caused by: No matching key found]

If we restart Krill, we are always able to login again immediately after the restart and for a (usually long) while thereafter.

I found the following information from Microsoft which leads me to think that Krill may be caching the signing key(s) upon startup and then verification starts failing after Microsoft has aged out all the keys that Krill knew about.

https://learn.microsoft.com/en-us/entra/identity-platform/signing-key-rollover

There should probably be a way for Krill to refresh the list of keys.

[partim]

Thank you for the report!

We discovered the same issue a while back with our own setup and fixed it in #1226. Because the code is currently in a bit of flux, I don’t want to make a new release just yet. However, depending on how annoying this is for you, we could backport it to the 0.14 branch and make a release there.

However, while I have you here, I’d like to ask you how much of Krill’s multiuser functionality you are using. Are you using OpenID just for login or also to centrally set access permissions for individual users possibly even for individual CAs? We are currently trying to simplify the authentication code quite a bit but don’t want to use features that are actually used.

[plevan74]

Thank you for the information about an upcoming fix.

To answer your question, we started using OpenID for authentication and then found that we could use the group membership facts to assign access levels too so we're now using it for authorization too. This is all for a single CA.