-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AzureAD .well-known config is partially invalid, making OAuth2 registration with the "common" or "organizations" endpoints impossible #12073
Comments
This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions. |
So markbates/goth (our underlying multi-authentication source) has a couple of azure backends. In order to integrate this as a new provider we would need an azure AD to test against though. |
I'm happy to help test with my dev AAD tenant. |
This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions. |
Still an issue.. |
[x]
):Description
A related bug was filed with Azure awhile ago, and I confirmed with that team that this bug is not in the roadmap to be fixed any time soon, because doing so requires considerable engineering effort. That bug is here:
MicrosoftDocs/azure-docs#38427
The TL;DR is that Azure's endpoint doesn't actually return a valid issuer URI in the .well-known response from the endpoint, if you are trying to use either the common or organizations endpoints. When you try to hit either of these, the .well-known response looks like this:
The correct issuer is in the URL of the .well-known config itself:
Gitea checks the issuer in the .well-known response, and since it doesn't match, it throws an HTTP 500 error after successful authentication.
I think this can be addressed one of two ways:
Alternatively, maybe Microsoft can be added as a preconfigured OAuth2 provider. I'm not a Go dev but I can help answer any questions related to Microsoft's implementation.
The text was updated successfully, but these errors were encountered: