search

DuendeSoftware / IdentityServer

The most flexible and standards-compliant OpenID Connect and OAuth 2.x framework for ASP.NET Core
https://duendesoftware.com/products/identityserver
Other
1.48k stars 343 forks source link

Consider adding more cache header options to `DiscoveryOptions` #1589

Open RolandGuijt opened 1 month ago

RolandGuijt commented 1 month ago

Please see https://github.com/DuendeSoftware/Support/issues/1399

josephdecock commented 1 month ago

ASP.NET Core has lots of built in caching support that has been improving over the past few releases. There's now both ResponseCaching (http header based) and OutputCaching (new in .net 7, controlled purely server side).

Anders brought up that we might benefit from using the built in endpoint infrastructure for better observability (https://github.com/DuendeSoftware/IdentityServer/issues/1575#issuecomment-2177902570). I think we could get some benefit from the framework's caching implementations as well.

Of course, that's a major change with big implications. We could always just add more options. There's about a dozen cache control directives possible (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#cache_directives). Which ones would we support? Should we try to respect request headers, as the framework's Response Cache does?

Paulcappaert commented 1 month ago

For our use case the stale-if-error directive on the response would be the most useful. We serve all our endpoints through a proxy. We want that proxy to be able to serve cached results for the JWKS endpoints when our instance is unavailable. The stale-if-error directive would ensure that the proxy can keep serving the JWKS from cache even if the origin is down when the cache max age runs out. The stale-while-revalidate would also be useful in this scenario.