/.well-known/openid-configuration cache-control

[lghinet]

Issue

Hello,
the problem i have is when a users goes from the main domain.com (dashboard) to pay.domain.com, which is another application, then hits the back button of the browser and comes back to the root domain, dashboard, (domain.com) and tries to get the well-known/openid-configuration again from sso, but is serverd from cache, from the subdomain app.
there is no cache control headers set on request . I use oidc client on both

Relevant parts of the log file

XMLHttpRequest cannot load https://sso.domain.com/.well-known/openid-configuration. The 'Access-Control-Allow-Origin' header has a value 'https://pay.domain.com' that is not equal to the supplied origin. Origin 'https://domain.com' is therefore not allowed access.

[brockallen]

If the metadata document does not support CORS, then you can set the data in manually on the settings. Check the wiki for more info.

[svieillard]

Using AADv2.0 I couldn't find how to fix CORS so I got it working by passing this settings object to the UserManager:

let settings: UserManagerSettings = {
        authority: 'https://login.microsoftonline.com/{tenant}/v2.0/',
        client_id: '{tenant}',
        redirect_uri: 'http://localhost:5000/',
        response_type: 'id_token token',
        scope: 'openid',
        loadUserInfo: false,
        metadata: {
            issuer: 'https://login.microsoftonline.com/{tenant}/v2.0',
            jwks_uri: 'https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys',
            end_session_endpoint: 'https://login.microsoftonline.com/{tenant}/oauth2/v2.0/logout"',
            authorization_endpoint: 'https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize'
        }
        signingKeys: [{signing_keys}]
}

I guess the important thing is to pass the metadata to prevent retrieving the well-known/openid-configuration and loadUserInfo: false to prevent a second call to the metadata endpoint trigged after a succesfull login when doing the callback that gets the token from the URL.

[brockallen]

Yep, that's what you need to do if there's no CORS on metdata endpoint.

[lghinet]

The metadata document does support CORS, but i dont think is a CORS problem.
the problem is that the request to openid-configuration is served from cache(StatusCode: 200 OK (from disk cache)) from the previous app, both authenticate through the same sso.
and the error is correct : Access-Control-Allow-Origin header = pay.domain.com (from the previous app ) and the Origin = domain.com from the current app.

if i disable cache in chrome, or hit refresh (with cache on) everything is ok

[brockallen]

Hmm, that sounds like a browser oddity... or maybe vary-by-origin should be added to the metadata document response. In fact, I think I saw an issue on the ASP.NET Core issue tracker about that exact issue: aspnet/CORS#97

[lghinet]

so do you think its bad to have a cache control header in oidc request for openid-configuration
i use identityserver3

[brockallen]

No, I don't think it's bad. You just also need a vary by origin response header.

[Stas-Buzunko]

@lghinet have u fixed it?

[lghinet]

nope,
having the same problem ?

[Farshidgolkarihagh]

Hi, I am having the same problem. Any suggestions on a fix? Thanks

[jonkerr]

In the Configure method, make sure that app.UseIdentityServer(); comes AFTER app.UseCors()

E.g.

app.UseCors("CorsPolicy");

// Must add CORS before UseIdentityServer
app.UseIdentityServer();

[brownbl1]

I know this is closed, but wanted to mention a related issue I'm having. if common is used instead of {tenant} I get

It's comparing https://login.microsoftonline.com/067e9632-ea4c-4ed9-9e6d-e294956e284b/v2.0 with https://login.microsoftonline.com/common/v2.0.

Did you find a way to get around this issue? If you know the tenant up front, then your app only works for a single tenant.

[brockallen]

Yes, that's a non-spec compliant discovery document tha azure invented for multi-tenancy.

[brownbl1]

@brockallen Thanks, got it now. I can work around it, but kind of a pain that there isn't a standard approach for this.

[brockallen]

@brockallen Thanks, got it now. I can work around it, but kind of a pain that there isn't a standard approach for this.

You can thanks the folks at Microsoft for doing this in a non-spec compliant way. Different token servers solve this in different ways.