Lifetime of openid configuration data and jkws data

[Clément OUDOT]

Hello,

first, I would like to introduce myself : I am the main developer of LemonLDAP::NG (http://lemonldap-ng.org) a WebSSO and Access Control free software. We already support CAS, OpenID 2.0 and SAML 2.0 protocols and I am working on adding OpenID Connect support.

I hope this list is the right place to ask some questions on OpenID Connect implementation. If not, please let me know.

So, a first question is about configuration data that we grab from configuration endpoint (.well-known/openid-configuration). For now, I decided to cache these information in my local configuration, with the possibility for an administrator to update them trough administration interface. But doing some tests, I saw that recently Google has changed the keys in his JKWS document (https://www.googleapis.com/oauth2/v2/certs).

So my question is: should we refresh configuration data / jkws data (which means a GET on configuration endpoint and jkws_uri endpoint every X minutes), or is it common to store these data in local configuration and let the administrator refresh them? Another related question: could we not have a 'serial number' parameter in configuration JSON document in order to be able to know if we already have the latest configuration?


Thanks a lot for your attention.


Clément OUDOT
LemonLDAP::NG - http://www.lemonldap-ng.org
LINAGORA - http://www.linagora.com

[Richer, Justin P.]

You can cache both the configuration and the JWKs based on regular HTTP cache control headers. If something doesn't work, it might be worth re-grabbing it. 

I don't see what a serial number would add to the configuration, since you always take the version currently at the URL no matter if it's changed or not.

 -- Justin

--
You received this message because you are subscribed to the Google Groups "OpenID Connect Interop" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openid-connect-in...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Clément OUDOT]

2014-11-25 17:26 GMT+01:00 Richer, Justin P. <jri...@mitre.org>:

You can cache both the configuration and the JWKs based on regular HTTP cache control headers. If something doesn't work, it might be worth re-grabbing it. 

My point was that grabbing the configuration is an administration operation. And if an error occurs when a user connect to the service, it may not be safe to change the configuration on the fly.

 

I don't see what a serial number would add to the configuration, since you always take the version currently at the URL no matter if it's changed or not.

But if the configuration has changed, the service should be reconfigured, which can have some impact on it. If the configuration has not changed, the code can decide to not touch anything.

Is there any good practice regarding the update of JKWS data? I mean, is it recommended to update keys regularly?

Clément.

[John Bradley]

Some implementations rotate keys daly and some even more often than that.

The http cache controll headders should be used to control caching.

The cache duration needs to be shorter than the key rollover period.  

AS should publish multiple signing keys with key_id so that the next key in the sequence is always in the meta-data when fetched.

John B.