Azure-docs: OpenID Connect Issuer doesn't match issuer in the metadata

[MaikuMori]

The discovery URL given for common endpoints is:

https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration

But the metadata document itself returns:

issuer: "https://login.microsoftonline.com/{tenantid}/v2.0"

The base part of these two should match according to the spec. This breaks OIDC Connect libraries which are rigid about the spec.

For example: https://github.com/coreos/go-oidc

See also https://github.com/coreos/go-oidc/issues/159 https://github.com/coreos/go-oidc/issues/212

If this is not the correct place where to file and issue let me know where I can do that.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 326f7173-a654-fda7-2438-6905da3fdbef
• Version Independent ID: 7dbc5a10-9d61-26e1-f532-973b4bdfae9a
• Content: How to build an app that can sign in any Azure AD user
• Content Source: articles/active-directory/develop/howto-convert-app-to-be-multi-tenant.md
• Service: active-directory
• Sub-service: develop
• GitHub Login: @rwike77
• Microsoft Alias: ryanwi

[neeleshray-msft]

@MaikuMori Thank you for your query. We will investigate and update the thread.

[MaikuMori]

The workaround that I found and documented here: https://github.com/coreos/go-oidc/issues/212#issuecomment-528805306 only works for the personal Microsoft account sign-in.

I still believe that the metadata server is not working according to OIDC spec and should never return issuer with value: https://login.microsoftonline.com/{tenantid}/v2.0. It even looks like a bug.

Obviously changing the output is a breaking change. What if there was a UUID alias like the one for consumers tenant, but instead for common? Then we could use that as metadata endpoint and that endpoints could respond with correct issuer just like the https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0 does.

[shashishailaj]

@MaikuMori Thank you for sharing your findings . We will engage with the content authors to get more clarity on this.

@rwike77 Could you please take a look at this issue and provide your thoughts on this ?

[codyfyi]

Thank you for looking into this!

I've also seen this issue prevent several OIDC compliant services from integrating with Microsoft. For example Amazon Cognito refuses to integrate because it correctly notices the iss in the JWT token does not match the .../{tenantid}/v2.0. issuer in Azure's .well-known endpoint and other auth services fail for the same reason.

This quirk makes Azure non-compliant with the OpenID Connect specification.

[rwike77]

@hpsin , can you comment on this? Thanks.

[hpsin]

Yes, this is unfortunately an inherent issue with the /common alias. By using /common, the app is indicating that they expect a user in any tenant (issuer) to be able to sign into the app. We reflect the ultimately chosen tenant in the issuer claim. This is especially important when there are tenant specific signing keys, where the app must know which jwks URI to visit in order to get the key used to sign the token.

@codeitcody - can you provide some other services that this has blocked? It would be helpful to understand who's using /common like this and encountering these issues.

Unfortunately there's no way at this time to make /common OIDC compliant - only our tenanted URLs (of which /consumers is one, as it's just an alias to the singleton MSA tenant) can be OIDC compliant. We can consider breaking tenant-specific signing keys (it's proprietary) and force those apps to build the jwks URI from scratch (s/common/$claims.tid/), or allow apps to opt-in to a /common issuer so that in the future they get expected values. I don't love the idea of making standards compliance opt-in though. We'll discuss internally on what's the least-bad way to address this, if possible.

[rwike77]

I followed up with engineering, unfortunately it's not possible to make /common OIDC compliant right now. Closing this doc issue, feel free to reopen if necessary. #please-close

[ClairelyClaire]

Is there any chance of this being fixed?

I happened upon this bug when I wanted to set up Microsoft SSO with Gitea. I can only allow auth to the consumers tenant thanks to this bug.

[hpsin]

Unfortunately not, we have to rev the entire platform (v3) to change the issuer.

[ClairelyClaire]

Is that in the roadmap?

[MaikuMori]

What about having both V2 and V3 up? That way old code can still function and newer code can use the standards compliant version.

[hpsin]

Not on the roadmap currently. We absolutely would have both supported concurrently (as well as v1) but making a radical change to the existing architecture is out of scope right now given our current workload.

[ClairelyClaire]

Ok. I suppose it's not the end of the world - my Gitea instance is just for people to file issues against my own projects, so I don't need AAD support.

Thanks for the details, though!

[tsuna]

How are we supposed to have use OIDC in multi-tenant apps with customers that use Azure as their identity provider?

issuer did not match the issuer returned by provider, expected "https://login.microsoftonline.com/common/v2.0" got "https://login.microsoftonline.com/{tenantid}/v2.0"

Do people hard-code an exception for the fact that Microsoft can't seem to implement OIDC properly?

[hpsin]

Yes - they validate tokens based on the issuer claim, rather than the authority. Or validate the token based on the keys (static across tenants) and signature only. The common endpoint is not OIDC compliant - only tenanted endpoints can be.