Identityserver4: Not possible to disable caching for discovery document

[NilsEngelbach]

To avoid caching of the discovery document the option ResponseCacheInterval is set to 0

options.Discovery.ResponseCacheInterval = 0

Expected behavior would be that the the no-cache headers are set correctly.
Current behavior no cache control header at all.

Fix provided here:

1598

[NilsEngelbach]

Would it also be possible to patch version 1.X ?

[leastprivilege]

Unlikely we have the time for that. Unless you do a PR to the aspnetcore1 branch.

But even then - it's a bit like backlog. You should move to v2.

[NilsEngelbach]

Ok thank you for the update!

[NilsEngelbach]

This issue still bothers me, so i investigated a little bit deeper.

Our problem:
There are multiple clients accessing the discovery document, they are all whitelisted in the allowed origins so the Access-Control-Allow-Origin Header was set correctly. Since there is no cache policy by default we had couple of issues with caching the discovery document (including the Access-Control-Allow-Origin Header) and throwing CORS issues if the cached document had different Access-Control-Allow-Origin Header than the origin.

The most obvious solution would be to disable caching completely, so the document is always refreshed.
But since this is not the most performant solution, we have searched for alternatives.

The right way to do this, is to add the Vary Header with Value Origin, this will make the Caches also considering the Origin when resolving requests.

W3C Cross-Origin Resource Sharing
https://www.w3.org/TR/cors/#resource-implementation

Resources that wish to enable themselves to be shared with multiple Origins but do not respond uniformly with "*" must in practice generate the Access-Control-Allow-Origin header dynamically in response to every request they wish to allow. As a consequence, authors of such resources should send a Vary: Origin HTTP header or provide other appropriate control directives to prevent caching of such responses, which may be inaccurate if re-used across-origins.

More Information about Vary Header:
https://www.fastly.com/blog/caching-cors
https://www.fastly.com/blog/best-practices-using-vary-header/

[brockallen]

If you need headers to be added to a response, then build your own middleware in front of IdentityServer that emits those headers on the response.

[NilsEngelbach]

Yes we already did, but still you might consider also adding this header in identityserver by default when using Access-Control-Allow-Origin

app.Use((context, next) =>
{
      if (context.Request.Path.ToString().Contains(".well-known"))
      {
            context.Response.Headers.Add("Vary", "Origin");
       }
       return next();
});

[brockallen]

Ah, you linked the PR already. Fixed.

[Zenuka]

We had the same issue; the browser (IE11) caches the Access-Control-Allow-Origin from the .well-known/* endpoint so we added the middleware NilsEngelbach suggested to fix this. Doesn't everyone have this issue if they have multiple clients?

[manuel-guilbault]

If you need headers to be added to a response, then build your own middleware in front of IdentityServer that emits those headers on the response.

I just stumbled on the same issue recently. IMO, since IdentityServer handles multiple clients out of the box, it should either properly handle HTTP caching of the discovery document for multiple clients (by setting a Vary: Origin header) or completely leave it to users to implement their own discovery document HTTP caching middleware. Currently, it does only half of the job.

[brockallen]

Ok, I'll look back into it: #3282

[manuel-guilbault]

@brockallen thanks a lot!

[brockallen]

de rien

[brockallen]

Ok, I pushed a fix for this for our 2.5 release.

[manuel-guilbault]

Awesome, thanks!

[lock[bot]]

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.