Q: Support for caching and/or rotating signing keys?

[ChineseWelshman]

Relying Parties and other Clients use the public keys made available from the jwks endpoint to validate the signature on tokens issued by Identity Server 4. The OIDC spec recommends using the HTTP Cache-Control Header option and the max-age directive to inform clients how long they can cache the public keys for before returning to the jwks_uri location to retrieve replacement keys from the IdP.

http://openid.net/specs/openid-connect-core-1_0.html#RotateEncKeys

There are good reasons to support this functionality:-

• Caching the keys improves the performance of the solution and reduces the load on the OP;
• In the rare chance that the private key is compromised, being able to limit the time 3rd parties rely on the currency of the public keys enable certificate revocation mitigations to be implemented to take effect at the next expiry of the cached keys.

1. Are there any existing configuration options to modify the behaviour of Identity Server 4 to support caching of public keys by relying parties and other clients?
2. If not, can support for this feature be added to the backlog?

Issue / Steps to reproduce the problem

Tracing an access token validation between a relying party and the OP, it appears that Identity Server does not include a Cache-Control option in the Header of a HTTP Response to a request to the jwks_uri endpoint.

[brockallen]

The OIDC spec recommends using the HTTP Cache-Control Header option and the max-age directive to inform clients how long they can cache the public keys

We have support for this on the DiscoveryOptions by setting ResponseCacheInterval. By default it's disabled, so you would need to enable this in production.

Support for rotating signing keys

We currently have support for automatically managing and rotating signing keys within IdentityServer, but this feature is only offered as a commercial add-on. If you're interested, send us an email: contact@identityserver.io.

[ChineseWelshman]

Hi Brock,

Thanks for sharing your initial thoughts on this.

The comments in the DiscoveryOptions.cs files state:

Sets the maxage value of the cache control header (in seconds) of the HTTP response. This gives clients a hint how often they should refresh their cached copy of the discovery document. If set to 0 no-cache headers will be set. Defaults to null, which does not set the header.>

This implies that the cache-control setting globally covers all the discovery metadata and not just the cacheable life of the jwks keys. Is this intentional? If so, what is the rationale behind setting this across all discovery metadata rather than specifically for the jwks?

[brockallen]

This implies that the cache-control setting globally covers all the discovery metadata and not just the cacheable life of the jwks keys. Is this intentional? If so, what is the rationale behind setting this across all discovery metadata rather than specifically for the jwks?

Nothing, really. It seemed sufficient to use the one setting for both.

[ChineseWelshman]

Ok, Thanks.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.