OAuth2 authentication, cannot get username after successful login

[FunDeckHermit]

• 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.

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:

Did something change to the API endpoints?

Screenshots

[KN4CK3R]

Works for me with the default OpenID provider:

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.

[pat-s]

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)

[quoing]

+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

[zeripath]

+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

[quoing]

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