Skip to content
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

OpenID Connect issue with Azure AD: implicit vs code authorization flow #6345

Closed
1 of 7 tasks
anoff opened this issue Mar 17, 2019 · 9 comments
Closed
1 of 7 tasks

OpenID Connect issue with Azure AD: implicit vs code authorization flow #6345

anoff opened this issue Mar 17, 2019 · 9 comments
Labels
type/enhancement An improvement of existing functionality

Comments

@anoff
Copy link

anoff commented Mar 17, 2019

  • Gitea version (or commit ref): docker gitea/gitea:1 (67f9ff4a24c9)
  • Git version: gitea/gitea:1 (67f9ff4a24c9)
  • Operating system: gitea/gitea:1 (67f9ff4a24c9) running on Ubuntu 16.04
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist:

Description

I want to use Azure Active Directory as an OAUTH2.0 provider via the OpenID Connect feature. Gitea contacts the AD correctly and the workflow on AD side executes correctly but then the callback fails.

image

According to microsoft docs response_type | Must include id_token for OpenID Connect sign-in but Gitea sends response_type: code as shown in the screenshot.

I did some research on the matter and it seems that Msft is following the implicit flow whereas Gitea uses the Authorization Code Flow.

What are your thoughts on the matter? Is this something that should be changed in the OpenID Connect adapter of Gitea or rather add an Azure AD OAUTH provider directly?

@OvermindDL1
Copy link
Contributor

That actually seems questionable. Authorization Code Flow should always be used for hosted servers, like Gitea. Implicit Flow is designed for things like public javascript apps. I'd wager there is probably some mis-set setting in Azure or so as you really don't want to be using the implicit flow for a hosted server (just as you really exceptionally don't want to use authorization code flow for a SPA).

@anoff
Copy link
Author

anoff commented Mar 21, 2019

Thanks for those insights, I don't know that much about the OpenID format. I will get in contact with Msft support and discuss this issue, will update with a solution.

@lafriks
Copy link
Member

lafriks commented Mar 21, 2019

I think this should be improved in Gitea as oauth should return token/flow that has been requested

@lafriks lafriks added the type/enhancement An improvement of existing functionality label Mar 21, 2019
@anoff
Copy link
Author

anoff commented Mar 23, 2019

@OvermindDL1 was correct, there was a configuration missing on Azure AD side. The docs are a mess about this.

If anyone ever comes across this issue again, you need to configure the AD application on Azure side to Default Client Type: yes. This forces AAD to follow the code flow.

image

@anoff anoff closed this as completed Mar 23, 2019
@Mr-Reca
Copy link

Mr-Reca commented May 2, 2019

Good afternoon,

I'm having the same issue. I followed @anoff answer and I still have the same problem.

I followed this link for the setup: https://blog.anoff.io/2019-03-23-configure-azure-ad-for-gitea/

I'm using Gitea 1.8 with MySQL on openSUSE Leap 42.1 and I have 2FA enabled in my Azure account.

@anoff
Copy link
Author

anoff commented May 2, 2019

Hey @Mr-Reca,

did you create a native app in Azure? When looking at your app registration the Authentication tab should be configured like this

image

Did you also set the correct tenant for the OpenID URL? Maybe you can share your config (w/o secret) and error messages you receive.

@Mr-Reca
Copy link

Mr-Reca commented May 2, 2019

Hey @anoff

Where can I check if my app is native or not? I've just followed your blog. I check the Authentication settings (Default client type) and I also checked the secrets, keys & IDs.

The only thing is that Azure forced me to use https. I created a certificate using gitea cert --host <hostname>.<domain> and I change the config file.

When I log in, I do the MFA and then the browser shows me the error AADSTS50011: The reply url specified in the request does not match the reply urls configured for the application: <client_id>.

The reply URL is the next one:
https://<hostname>.<domain>:3000/user/oauth2/<app_name>/callback

The OpenID URL is the next one:
https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration

Do you want the config and some log files in case I missed something?

Thank you so much,

@anoff
Copy link
Author

anoff commented May 2, 2019 via email

@pyoungberg
Copy link

If you're using Azure App Proxy make sure you add the root url as a Reply URI in addition to the OpenID URI. This fixes the "not match the reply urls" error

@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/enhancement An improvement of existing functionality
Projects
None yet
Development

No branches or pull requests

5 participants