github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-24 23:46:30 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

OAuth2 authentication, cannot get username after successful login #7501

New Issue
Closed
opened 2025-11-02 07:27:40 -06:00 by GiteaMirror · 5 comments
GiteaMirror commented 2025-11-02 07:27:40 -06:00
Owner
Copy Link

Originally created by @FunDeckHermit on GitHub (Jun 24, 2021).

  • Gitea version (or commit ref): latest (docker)
  • Git version: 2.30.2
  • Operating system: dockerized
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
  • Log gist:

Description

I'm running Vouch Proxy, which used the user-management system and the Oauth2 provider of Gitea to validate users. After updating Vouch Proxy and Gitea to their latest version authentication application failed. After some digging I found that Gitea wasn't sending a username back to Vouch Proxy.

image

Error while retrieving user info after successful login at the OAuth provider: oauth2: cannot fetch token. 
Response: {"error":"unauthorized_client","error_description":"client is not authorized"}

The same message was found in the Gitea logs:

server_1  | 2021/06/24 14:47:10 Started GET /login/oauth/authorize?client_id=5c496697-4b21-464c-9f46-bc3ea2e5f261&code_challenge=A8sIdk0unMIHC653omRFIXi2hnmsH3gq_oM-2wzuti8&code_challenge_method=S256&redirect_uri=https%3A%2F%2Fvouch.doeber.nl%2Fauth&response_type=code&scope=read%3Auser&state=AEFsX8Tfz32rAU9nZBy4kDFK5TSL2v5 for 192.168.178.30:40354
server_1  | 2021/06/24 14:47:10 Completed GET /login/oauth/authorize?client_id=5c496697-4b21-464c-9f46-bc3ea2e5f261&code_challenge=A8sIdk0unMIHC653omRFIXi2hnmsH3gq_oM-2wzuti8&code_challenge_method=S256&redirect_uri=https%3A%2F%2Fvouch.doeber.nl%2Fauth&response_type=code&scope=read%3Auser&state=AEFsX8Tfz32rAU9nZBy4kDFK5TSL2v5 302 Found in 1.042938ms
server_1  | 2021/06/24 14:47:10 Started GET /user/login for 192.168.178.30:40356
server_1  | 2021/06/24 14:47:10 Completed GET /user/login 200 OK in 9.860591ms
server_1  | 2021/06/24 14:47:10 Started GET /assets/css/index.css?v=68708fc921ee7542bbeb77c63470f7bf for 192.168.178.30:40358
server_1  | 2021/06/24 14:47:10 Completed GET /assets/css/index.css?v=68708fc921ee7542bbeb77c63470f7bf 200 OK in 1.277295ms
server_1  | 2021/06/24 14:47:10 Started GET /assets/js/index.js?v=68708fc921ee7542bbeb77c63470f7bf for 192.168.178.30:40364
server_1  | 2021/06/24 14:47:10 Completed GET /assets/js/index.js?v=68708fc921ee7542bbeb77c63470f7bf 200 OK in 1.141246ms
server_1  | 2021/06/24 14:47:10 Started GET /assets/img/logo.svg for 192.168.178.30:40366
server_1  | 2021/06/24 14:47:10 Completed GET /assets/img/logo.svg 200 OK in 405.598��s
server_1  | 2021/06/24 14:47:37 Started POST /user/login for 192.168.178.30:40378
server_1  | 2021/06/24 14:47:37 Completed POST /user/login 302 Found in 136.437286ms
server_1  | 2021/06/24 14:47:37 Started GET /login/oauth/authorize?client_id=5c496697-4b21-464c-9f46-bc3ea2e5f261&code_challenge=A8sIdk0unMIHC653omRFIXi2hnmsH3gq_oM-2wzuti8&code_challenge_method=S256&redirect_uri=https%3A%2F%2Fvouch.doeber.nl%2Fauth&response_type=code&scope=read%3Auser&state=AEFsX8Tfz32rAU9nZBy4kDFK5TSL2v5 for 192.168.178.30:40380
server_1  | 2021/06/24 14:47:37 Completed GET /login/oauth/authorize?client_id=5c496697-4b21-464c-9f46-bc3ea2e5f261&code_challenge=A8sIdk0unMIHC653omRFIXi2hnmsH3gq_oM-2wzuti8&code_challenge_method=S256&redirect_uri=https%3A%2F%2Fvouch.doeber.nl%2Fauth&response_type=code&scope=read%3Auser&state=AEFsX8Tfz32rAU9nZBy4kDFK5TSL2v5 302 Found in 18.569637ms
server_1  | 2021/06/24 14:48:05 Started POST /login/oauth/access_token for 192.168.178.30:40408
server_1  | 2021/06/24 14:48:05 Completed POST /login/oauth/access_token 400 Bad Request in 72.235882ms
server_1  | 2021/06/24 14:48:05 Started POST /login/oauth/access_token for 192.168.178.30:40410
server_1  | 2021/06/24 14:48:05 Completed POST /login/oauth/access_token 400 Bad Request in 65.530209ms

After looking at the api endpoint (swagger.v1.json) on my machine it seems to be the same as the default Vouch Proxy settings for Gitea.
My Vouch Proxy settings:
image

Did something change to the API endpoints?

Screenshots

image

Originally created by @FunDeckHermit on GitHub (Jun 24, 2021). <!-- NOTE: If your issue is a security concern, please send an email to security@gitea.io instead of opening a public issue --> <!-- 1. Please speak English, this is the language all maintainers can speak and write. 2. Please ask questions or configuration/deploy problems on our Discord server (https://discord.gg/gitea) or forum (https://discourse.gitea.io). 3. Please take a moment to check that your issue doesn't already exist. 4. Make sure it's not mentioned in the FAQ (https://docs.gitea.io/en-us/faq) 5. Please give all relevant information below for bug reports, because incomplete details will be handled as an invalid report. --> - Gitea version (or commit ref): latest (docker) - Git version: 2.30.2 - Operating system: dockerized <!-- Please include information on whether you built gitea yourself, used one of our downloads or are using some other package --> <!-- Please also tell us how you are running gitea, e.g. if it is being run from docker, a command-line, systemd etc. ---> <!-- If you are using a package or systemd tell us what distribution you are using --> - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - Log gist: <!-- It really is important to provide pertinent logs --> <!-- Please read https://docs.gitea.io/en-us/logging-configuration/#debugging-problems --> <!-- In addition, if your problem relates to git commands set `RUN_MODE=dev` at the top of app.ini --> ## Description I'm running Vouch Proxy, which used the user-management system and the Oauth2 provider of Gitea to validate users. After updating Vouch Proxy and Gitea to their latest version authentication application failed. After some digging I found that Gitea wasn't sending a username back to Vouch Proxy. ![image](https://user-images.githubusercontent.com/5075692/123267248-16d7fc00-d4fd-11eb-8b7e-b678ea60ca11.png) ``` Error while retrieving user info after successful login at the OAuth provider: oauth2: cannot fetch token. Response: {"error":"unauthorized_client","error_description":"client is not authorized"} ``` The same message was found in the Gitea logs: ``` server_1 | 2021/06/24 14:47:10 Started GET /login/oauth/authorize?client_id=5c496697-4b21-464c-9f46-bc3ea2e5f261&code_challenge=A8sIdk0unMIHC653omRFIXi2hnmsH3gq_oM-2wzuti8&code_challenge_method=S256&redirect_uri=https%3A%2F%2Fvouch.doeber.nl%2Fauth&response_type=code&scope=read%3Auser&state=AEFsX8Tfz32rAU9nZBy4kDFK5TSL2v5 for 192.168.178.30:40354 server_1 | 2021/06/24 14:47:10 Completed GET /login/oauth/authorize?client_id=5c496697-4b21-464c-9f46-bc3ea2e5f261&code_challenge=A8sIdk0unMIHC653omRFIXi2hnmsH3gq_oM-2wzuti8&code_challenge_method=S256&redirect_uri=https%3A%2F%2Fvouch.doeber.nl%2Fauth&response_type=code&scope=read%3Auser&state=AEFsX8Tfz32rAU9nZBy4kDFK5TSL2v5 302 Found in 1.042938ms server_1 | 2021/06/24 14:47:10 Started GET /user/login for 192.168.178.30:40356 server_1 | 2021/06/24 14:47:10 Completed GET /user/login 200 OK in 9.860591ms server_1 | 2021/06/24 14:47:10 Started GET /assets/css/index.css?v=68708fc921ee7542bbeb77c63470f7bf for 192.168.178.30:40358 server_1 | 2021/06/24 14:47:10 Completed GET /assets/css/index.css?v=68708fc921ee7542bbeb77c63470f7bf 200 OK in 1.277295ms server_1 | 2021/06/24 14:47:10 Started GET /assets/js/index.js?v=68708fc921ee7542bbeb77c63470f7bf for 192.168.178.30:40364 server_1 | 2021/06/24 14:47:10 Completed GET /assets/js/index.js?v=68708fc921ee7542bbeb77c63470f7bf 200 OK in 1.141246ms server_1 | 2021/06/24 14:47:10 Started GET /assets/img/logo.svg for 192.168.178.30:40366 server_1 | 2021/06/24 14:47:10 Completed GET /assets/img/logo.svg 200 OK in 405.598��s server_1 | 2021/06/24 14:47:37 Started POST /user/login for 192.168.178.30:40378 server_1 | 2021/06/24 14:47:37 Completed POST /user/login 302 Found in 136.437286ms server_1 | 2021/06/24 14:47:37 Started GET /login/oauth/authorize?client_id=5c496697-4b21-464c-9f46-bc3ea2e5f261&code_challenge=A8sIdk0unMIHC653omRFIXi2hnmsH3gq_oM-2wzuti8&code_challenge_method=S256&redirect_uri=https%3A%2F%2Fvouch.doeber.nl%2Fauth&response_type=code&scope=read%3Auser&state=AEFsX8Tfz32rAU9nZBy4kDFK5TSL2v5 for 192.168.178.30:40380 server_1 | 2021/06/24 14:47:37 Completed GET /login/oauth/authorize?client_id=5c496697-4b21-464c-9f46-bc3ea2e5f261&code_challenge=A8sIdk0unMIHC653omRFIXi2hnmsH3gq_oM-2wzuti8&code_challenge_method=S256&redirect_uri=https%3A%2F%2Fvouch.doeber.nl%2Fauth&response_type=code&scope=read%3Auser&state=AEFsX8Tfz32rAU9nZBy4kDFK5TSL2v5 302 Found in 18.569637ms server_1 | 2021/06/24 14:48:05 Started POST /login/oauth/access_token for 192.168.178.30:40408 server_1 | 2021/06/24 14:48:05 Completed POST /login/oauth/access_token 400 Bad Request in 72.235882ms server_1 | 2021/06/24 14:48:05 Started POST /login/oauth/access_token for 192.168.178.30:40410 server_1 | 2021/06/24 14:48:05 Completed POST /login/oauth/access_token 400 Bad Request in 65.530209ms ``` After looking at the api endpoint (swagger.v1.json) on my machine it seems to be the same as the [default Vouch Proxy](https://github.com/vouch/vouch-proxy/blob/master/config/config.yml_example_gitea) settings for Gitea. My Vouch Proxy settings: ![image](https://user-images.githubusercontent.com/5075692/123268697-90bcb500-d4fe-11eb-8691-d486953e47a8.png) Did something change to the API endpoints? ## Screenshots ![image](https://user-images.githubusercontent.com/5075692/123266815-a3ce8580-d4fc-11eb-881a-c9bb4dd8c054.png) <!-- **If this issue involves the Web Interface, please include a screenshot** -->
GiteaMirror added the topic/authentication label 2025-11-02 07:27:40 -06:00
GiteaMirror commented 2025-11-02 07:27:41 -06:00
Author
Owner
Copy Link

@KN4CK3R commented on GitHub (Jun 27, 2021):

Works for me with the default OpenID provider:
grafik

oauth:
  provider: oidc
  client_id: dee5d33f-...
  client_secret: Xtt48AQ5R...
  auth_url: https://dev-gitea.local-lan/login/oauth/authorize
  token_url: https://dev-gitea.local-lan/login/oauth/access_token
  user_info_url: https://dev-gitea.local-lan/login/oauth/userinfo
  scopes:
    - openid
    - email
    - profile
  callback_url: http://localhost:9090/auth

I did not test the Github provider.

@KN4CK3R commented on GitHub (Jun 27, 2021): Works for me with the default OpenID provider: ![grafik](https://user-images.githubusercontent.com/1666336/123559223-0b096580-d79b-11eb-81dd-9846c65b8d85.png) ``` oauth: provider: oidc client_id: dee5d33f-... client_secret: Xtt48AQ5R... auth_url: https://dev-gitea.local-lan/login/oauth/authorize token_url: https://dev-gitea.local-lan/login/oauth/access_token user_info_url: https://dev-gitea.local-lan/login/oauth/userinfo scopes: - openid - email - profile callback_url: http://localhost:9090/auth ``` I did not test the Github provider.
GiteaMirror commented 2025-11-02 07:27:41 -06:00
Author
Owner
Copy Link

@pat-s commented on GitHub (Jul 20, 2021):

Seeing the same issue when sending webhooks from Gitea to Drone on our instance since a few hours (NGINX proxy).

The HTTP request is missing the username entry

      "author": {
        "name": "$REDACTED",
        "email": "$REDACTED",
        "username": ""
      },

For the last successful submission (just a few hours ago) of the webhook, the HTTP request sent also looked completely different. On the first look it seems a different (wrong?) API endpoint is now used?

New

{
  "secret": "$REDACTED",
  "ref": "refs/heads/main",
  "before": "$REDACTED",
  "after": "$REDACTED",
  "compare_url": "",
  "commits": [
    {
      "id": "$REDACTED",
      "message": "$REDACTED",
      "url": "$REDACTED",
      "author": {
        "name": "$REDACTED",
        "email": "$REDACTED",
        "username": ""
      },
      "committer": {
        "name": "$REDACTED",
        "email": "$REDACTED",
        "username": ""
      },

Last successful webhook

{
  "secret": "$REDACTED",
  "ref": "$REDACTED",
  "ref_type": "branch",
  "pusher_type": "user",
  "repository": {
    "id": 141,
    "owner": {"id":15,"login":"devops","full_name":"","email":"","avatar_url":"$REDACTED","language":"","is_admin":false,"last_login":"0001-01-01T00:00:00Z","created":"2021-04-19T20:09:21+02:00","restricted":false,"username":"$REDACTED"},
    "name": "$REDACTED-aws",
    "full_name": "$REDACTED",
    "description": "",
    "empty": false,
    "private": false,
    "fork": false,
    "template": false,
    "parent": null,
    "mirror": false,
    "size": 405,

(I'm on v1.14.5)

@pat-s commented on GitHub (Jul 20, 2021): Seeing the same issue when sending webhooks from Gitea to Drone on our instance since a few hours (NGINX proxy). The HTTP request is missing the `username` entry ``` "author": { "name": "$REDACTED", "email": "$REDACTED", "username": "" }, ``` For the last successful submission (just a few hours ago) of the webhook, the HTTP request sent also looked completely different. On the first look it seems a different (wrong?) API endpoint is now used? ## New ``` { "secret": "$REDACTED", "ref": "refs/heads/main", "before": "$REDACTED", "after": "$REDACTED", "compare_url": "", "commits": [ { "id": "$REDACTED", "message": "$REDACTED", "url": "$REDACTED", "author": { "name": "$REDACTED", "email": "$REDACTED", "username": "" }, "committer": { "name": "$REDACTED", "email": "$REDACTED", "username": "" }, ``` ## Last successful webhook ``` { "secret": "$REDACTED", "ref": "$REDACTED", "ref_type": "branch", "pusher_type": "user", "repository": { "id": 141, "owner": {"id":15,"login":"devops","full_name":"","email":"","avatar_url":"$REDACTED","language":"","is_admin":false,"last_login":"0001-01-01T00:00:00Z","created":"2021-04-19T20:09:21+02:00","restricted":false,"username":"$REDACTED"}, "name": "$REDACTED-aws", "full_name": "$REDACTED", "description": "", "empty": false, "private": false, "fork": false, "template": false, "parent": null, "mirror": false, "size": 405, ``` (I'm on v1.14.5)
GiteaMirror commented 2025-11-02 07:27:41 -06:00
Author
Owner
Copy Link

@quoing commented on GitHub (Aug 10, 2021):

+1 .. upgraded to latest gitea, since upgrade OAuth with drone is NOT working. There were no changes in configuration.

Gitea is returning 400 Bad Request..

gitea_1    | 2021/08/10 11:17:20 ...auth2_application.go:131:getOAuth2ApplicationByClientID() [I] [SQL] SELECT "id", "uid", "name", "client_id", "client_secret", "redirect_uris", "created_unix", "updated_unix" FROM "oauth2_application" WHERE (client_id = $1) LIMIT 1 [*redacted*] - 521.698µs
gitea_1    | 2021/08/10 11:17:20 Completed POST /login/oauth/access_token 400 Bad Request in 103.610349ms
@quoing commented on GitHub (Aug 10, 2021): +1 .. upgraded to latest gitea, since upgrade OAuth with drone is NOT working. There were no changes in configuration. Gitea is returning 400 Bad Request.. ``` gitea_1 | 2021/08/10 11:17:20 ...auth2_application.go:131:getOAuth2ApplicationByClientID() [I] [SQL] SELECT "id", "uid", "name", "client_id", "client_secret", "redirect_uris", "created_unix", "updated_unix" FROM "oauth2_application" WHERE (client_id = $1) LIMIT 1 [*redacted*] - 521.698µs gitea_1 | 2021/08/10 11:17:20 Completed POST /login/oauth/access_token 400 Bad Request in 103.610349ms ```
GiteaMirror commented 2025-11-02 07:27:42 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Aug 10, 2021):

+1 .. upgraded to latest gitea, since upgrade OAuth with drone is NOT working. There were no changes in configuration.

Gitea is returning 400 Bad Request..

gitea_1    | 2021/08/10 11:17:20 ...auth2_application.go:131:getOAuth2ApplicationByClientID() [I] [SQL] SELECT "id", "uid", "name", "client_id", "client_secret", "redirect_uris", "created_unix", "updated_unix" FROM "oauth2_application" WHERE (client_id = $1) LIMIT 1 [*redacted*] - 521.698µs
gitea_1    | 2021/08/10 11:17:20 Completed POST /login/oauth/access_token 400 Bad Request in 103.610349ms

This is likely related to #16010 (please read the opening comment we'll try to keep that updated with the correct information.)

The current temporary 1.15 blog post looks like:

https://gitea.com/gitea/blog/wiki/v1.15.0/#exclamation-asymmetric-jwt-signing-key-16010-https-github-com-go-gitea-gitea-pull-16010

@zeripath commented on GitHub (Aug 10, 2021): > +1 .. upgraded to latest gitea, since upgrade OAuth with drone is NOT working. There were no changes in configuration. > > Gitea is returning 400 Bad Request.. > > ``` > gitea_1 | 2021/08/10 11:17:20 ...auth2_application.go:131:getOAuth2ApplicationByClientID() [I] [SQL] SELECT "id", "uid", "name", "client_id", "client_secret", "redirect_uris", "created_unix", "updated_unix" FROM "oauth2_application" WHERE (client_id = $1) LIMIT 1 [*redacted*] - 521.698µs > gitea_1 | 2021/08/10 11:17:20 Completed POST /login/oauth/access_token 400 Bad Request in 103.610349ms > ``` This is likely related to #16010 (please read the opening comment we'll try to keep that updated with the correct information.) The current temporary 1.15 blog post looks like: https://gitea.com/gitea/blog/wiki/v1.15.0/#exclamation-asymmetric-jwt-signing-key-16010-https-github-com-go-gitea-gitea-pull-16010
GiteaMirror commented 2025-11-02 07:27:42 -06:00
Author
Owner
Copy Link

@quoing commented on GitHub (Aug 10, 2021):

@zeripath thank you! I somehow missed this in release notes. Everything is working now.

@quoing commented on GitHub (Aug 10, 2021): @zeripath thank you! I somehow missed this in release notes. Everything is working now.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label topic/authentication
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#7501
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?