OpenID Connect Issuer doesn't match issuer in the metadata #38427
Comments
|
@MaikuMori Thank you for your query. We will investigate and update the thread. |
|
The workaround that I found and documented here: coreos/go-oidc#212 (comment) 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: Obviously changing the output is a breaking change. What if there was a UUID alias like the one for |
|
@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 ? |
|
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 This quirk makes Azure non-compliant with the OpenID Connect specification. |
|
@hpsin , can you comment on this? Thanks. |
|
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. |
|
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 |
|
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. |
|
Unfortunately not, we have to rev the entire platform (v3) to change the issuer. |
|
Is that in the roadmap? |
|
What about having both |
|
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. |
|
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! |
|
How are we supposed to have use OIDC in multi-tenant apps with customers that use Azure as their identity provider? Do people hard-code an exception for the fact that Microsoft can't seem to implement OIDC properly? |
|
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. |
|
In a possible v3, as mentioned above. We cannot break our existing apps. Use of B2C here is out of scope - I believe B2C requires you to use the special B2C issuer and endpoints, no? |
|
@hpsin what about another keyword like common-compliant, or something that allows the issuer to be what it is suppose to be. I would also argue a major version bump is allowed to break apps, but that is another discussion. |
|
Good call - we usually think about this in terms of clients getting access tokens, and resources validating those access tokens, with no control over how the access token was requested (e.g. they're often requested from v1, even if you're running a v2 resource). However, we could indeed fix this with an ID token issuer optional claim, or a new issuer for metadata. Would you prefer to leave code as-is, and set an optional claim in the app config, or use a new issuer (common-compliant, e.g.) ? |
|
@hpsin this is a good question, I would think a new issuer would have the most flexibility in the case that an app maybe uses multiple oidc libraries, web vs phone etc. Thank you for even considering this! |
|
That makes sense - it's a run-time decision tightly coupled to the code, not the app registration. I'll get some other folks to give some input. Thank you for the idea and helping tease out the distinctions here. |
|
I came across this issue adding OAuth2 to my application. What I'd like to do is allow any email of any organization to use my application by signing into Azure. All I really need is the authorized email account, then my application creates its own bearer token that is used throughout as only identity verification is required. I am okay if personal accounts are not used. I am using I can't use the tenented enpoint because I want ANY organization to be able to authenticate with ease. Am I totally out of luck? Can I really only support my own organization authenticating? What do I have to do? Any pointers are appreciated. Edit: I can use the |
According to the OpenID Connect specs, the /.well-known/openid-configuration should contain an `issuer` field that matches the URL used to fetch the configuration metadata: > The issuer value returned MUST be identical to the Issuer URL that was directly used to retrieve the configuration information. This MUST also be identical to the iss Claim value in ID Tokens issued from this Issuer. https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig The OIDC solutions provided from Azure for example when using the Azure Active Directory B2C currently doesn't adhere to the OpenID Connect spec and returns a wrong issuer. Since that's something they won't fix that fast (or maybe not even at all) we should introduce a configuration to support overriding the issuer URL. MicrosoftDocs/azure-docs#38427 (comment)
#212) According to the OpenID Connect specs, the /.well-known/openid-configuration should contain an `issuer` field that matches the URL used to fetch the configuration metadata: > The issuer value returned MUST be identical to the Issuer URL that was directly used to retrieve the configuration information. This MUST also be identical to the iss Claim value in ID Tokens issued from this Issuer. https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig The OIDC solutions provided from Azure for example when using the Azure Active Directory B2C currently doesn't adhere to the OpenID Connect spec and returns a wrong issuer. Since that's something they won't fix that fast (or maybe not even at all) we should introduce a configuration to support overriding the issuer URL. MicrosoftDocs/azure-docs#38427 (comment)
|
Is there already a fix for this so we can use commonv2 or something else I need it to support work and personal accounts for Amazon cognito |
|
This issue is affecting all services which require an OIDC compliant upstream service, including the largest Auth OSS ecosystem in the world: https://github.com/ory We'd be happy to assist when v3 comes out, Ory Hydra is an excellent OIDC compliant authz server ;) |
|
I'm running into this issue trying to test Azure AD as an openid provider for our software. Setting |
Hi, did you ever get to the bottom of this? My ID tokens have the correct tenanted issuer but the access tokens do not. Thanks |
|
@jonathandavis5 Yep... unfortunately not much you can do here. Azure is simply not OIDC compliant. 👎 |
|
It's been 4 years, is this seriously not resolved? |
|
Firebase authentication is also refusing to work without a strict OpenID Connect implementation. For now the only way around this issue is using custom policies, as documented here: https://docs.gitlab.com/ee/administration/auth/oidc.html#configure-microsoft-azure-active-directory-b2c Can't wait for this issue to be fixed. |
and others
The discovery URL given for
commonendpoints is:But the metadata document itself returns:
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 coreos/go-oidc#159 coreos/go-oidc#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.
The text was updated successfully, but these errors were encountered: