Can jwks_uri (JSON Web Key Set URI) be safely cached?

[Justin Holzer]

Once the JSON Web Key Set URI is discovered from the authorization server, is it safe to cache it and assume that it will not change as long as the authorization server does not change as well, or does it need to be rediscovered every time I need to validate an OIDC ID Token for SSO?

I'm building a Cerner integration that will primarily involve providers and other clinical staff using SSO to allow them to automatically sign in to our system from PowerChart, so we'll need to verify the OpenID Connect/ID tokens. I'd like to keep the back-and-forth HTTP requests to a minimum, and cache as much information as safely possible, to make the SSO process as efficient as possible.

[Jenni Syed (Cerner)]

Hi Justin,

The application should use the Cache-Control header to determine caching period, but also handle the workflow when you receive a token with a key id that you don't have cached already.

Regards,

Jenni

[Justin Holzer]

Sorry if my initial question wasn't clear...

My question actually wasn't about caching the keys themselves (which I do not plan to cache for now), but instead was about the URL that's used for retrieving the JSON Web Key Set (the value of the "jwks_uri" property from OIDC discovery). And when I talk about caching, I really mean storing the URL in my application's backend database. I just want to see if that URL is something that could change, or will remain the same (barring a particular Cerner customer changing their authentication system)

It just seems like there are a lot of extra HTTPS calls that are required in order to validate the OIDC ID Token. Do I really need to make the call to the ".well-known/openid-configuration" endpoint every single time a user logs in, just to fetch the jwks_uri value, or can I save that value and reuse it on subsequent user logins, to reduce the number of HTTP calls during the ID token verification process?

Thanks!

Justin

[Matt Randall (Cerner)]

I went back to the OIDC specification and was surprised to find no information about cache mechanisms for openid-configuration documents.  Presumably, caches per RFC 7234 should apply.  That being said, it looks like our implementation is returning "no-cache", which is something I plan to have rectified.  From a standards perspective, I'd recommend honoring standard HTTP 1.1 cache control, and same with the keys themselves.

The JWKS URL could theoretically change, but there is no current mechanism by which that would occur.  There are no current plans to move it within Cerner's implementation.  The actual keys rotate quite frequently.