github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-07-16 13:20:06 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

OAuth public clients seem broken since 1.22 #14282

New Issue
Closed
opened 2025-11-02 11:08:28 -06:00 by GiteaMirror · 8 comments
GiteaMirror commented 2025-11-02 11:08:28 -06:00
Owner
Copy Link

Originally created by @schnusch on GitHub (Mar 21, 2025).

Description

When a confidential client tries to authenticate without Gitea throught PKCE the error {"error":"unauthorized_client","error_description":"failed PKCE code challenge"} is returned. Only versions 1.22 and up seem to be broken.

I tested with the following docker-compose.yaml:

networks:
  p2p:
    external: false
    internal: true

services:
  gitea:
    image: docker.gitea.com/gitea:1.21
    restart: unless-stopped
    environment:
      USER_UID: "1000"
      USER_GID: "1000"
      GITEA__cors__ENABLED: "true"
      GITEA__security__INSTALL_LOCK: "true"
    volumes:
    - ./temp:/data
    - /etc/localtime:/etc/localtime:ro
    - /dev/null:/etc/timezone:ro
    ports:
    - "3000:3000"
    networks:
    - p2p

  oauth2-proxy:
    image: quay.io/oauth2-proxy/oauth2-proxy
    restart: unless-stopped
    depends_on:
    - gitea
    environment:
      OAUTH2_PROXY_HTTP_ADDRESS: http://0.0.0.0:4180
      OAUTH2_PROXY_PROVIDER: github
      OAUTH2_PROXY_PROVIDER_DISPLAY_NAME: Gitea
      OAUTH2_PROXY_LOGIN_URL: http://localhost:3000/login/oauth/authorize
      OAUTH2_PROXY_REDEEM_URL: http://gitea:3000/login/oauth/access_token
      OAUTH2_PROXY_VALIDATE_URL: http://gitea:3000/api/v1/user/emails
      OAUTH2_PROXY_COOKIE_SECRET: dvfrzQ8kHYx260vV
      OAUTH2_PROXY_CLIENT_ID: 291c99d2-2727-49da-a26c-4c315fda95a7
      OAUTH2_PROXY_CLIENT_SECRET: gto_cyncn56ksancs3zjdwajrzc2bp2c7cfa3yzefixvvd4ziq4bggbq
      OAUTH2_PROXY_REDIRECT_URL: http://localhost:4180/oauth2/callback
      OAUTH2_PROXY_EMAIL_DOMAINS: "*"
      OAUTH2_PROXY_CODE_CHALLENGE_METHOD: plain
    ports:
    - "4180:4180"
    networks:
    - p2p

  1. Setup Gitea 1.21 at http://localhost:3000.

    • register a user
    • create an application, do not tick confidential client

  2. Update OAUTH2_PROXY_CLIENT_ID and OAUTH2_PROXY_CLIENT_SECRET accordingly.

  3. Restart docker-compose.

  4. Open http://localhost:4180.

  5. Log-in through Gitea.

    On first login oauth2-proxy returned the error {"error":"unauthorized_client","error_description":"failed PKCE code challenge"} as well, but this might be a fluke because subsequent tries work.

  6. Make sure oauth2-proxy is authenticated. (It will return 404 instead of asking for a login.)

  7. Update docker image to docker.gitea.com/gitea:1.22.

  8. Restart docker-compose.

  9. Clear login data in the browser.

  10. Open http://localhost:4180.

  11. Every authentication attempt will result in the error {"error":"unauthorized_client","error_description":"failed PKCE code challenge"}.

I first encountered the error after a custom application stopped working after updating Gitea but tried to reproduce it with a more mature implementation.

Gitea Version

v1.22

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

docker-compose

Database

MySQL/MariaDB

Originally created by @schnusch on GitHub (Mar 21, 2025). ### Description When a confidential client tries to authenticate without Gitea throught PKCE the error `{"error":"unauthorized_client","error_description":"failed PKCE code challenge"}` is returned. Only versions 1.22 and up seem to be broken. I tested with the following `docker-compose.yaml`: ```yaml networks: p2p: external: false internal: true services: gitea: image: docker.gitea.com/gitea:1.21 restart: unless-stopped environment: USER_UID: "1000" USER_GID: "1000" GITEA__cors__ENABLED: "true" GITEA__security__INSTALL_LOCK: "true" volumes: - ./temp:/data - /etc/localtime:/etc/localtime:ro - /dev/null:/etc/timezone:ro ports: - "3000:3000" networks: - p2p oauth2-proxy: image: quay.io/oauth2-proxy/oauth2-proxy restart: unless-stopped depends_on: - gitea environment: OAUTH2_PROXY_HTTP_ADDRESS: http://0.0.0.0:4180 OAUTH2_PROXY_PROVIDER: github OAUTH2_PROXY_PROVIDER_DISPLAY_NAME: Gitea OAUTH2_PROXY_LOGIN_URL: http://localhost:3000/login/oauth/authorize OAUTH2_PROXY_REDEEM_URL: http://gitea:3000/login/oauth/access_token OAUTH2_PROXY_VALIDATE_URL: http://gitea:3000/api/v1/user/emails OAUTH2_PROXY_COOKIE_SECRET: dvfrzQ8kHYx260vV OAUTH2_PROXY_CLIENT_ID: 291c99d2-2727-49da-a26c-4c315fda95a7 OAUTH2_PROXY_CLIENT_SECRET: gto_cyncn56ksancs3zjdwajrzc2bp2c7cfa3yzefixvvd4ziq4bggbq OAUTH2_PROXY_REDIRECT_URL: http://localhost:4180/oauth2/callback OAUTH2_PROXY_EMAIL_DOMAINS: "*" OAUTH2_PROXY_CODE_CHALLENGE_METHOD: plain ports: - "4180:4180" networks: - p2p ``` 1. Setup Gitea 1.21 at <http://localhost:3000>. * register a user * create an application, do not tick confidential client 2. Update `OAUTH2_PROXY_CLIENT_ID` and `OAUTH2_PROXY_CLIENT_SECRET` accordingly. 3. Restart `docker-compose`. 4. Open <http://localhost:4180>. 5. Log-in through Gitea. On first login `oauth2-proxy` returned the error `{"error":"unauthorized_client","error_description":"failed PKCE code challenge"}` as well, but this might be a fluke because subsequent tries work. 6. Make sure `oauth2-proxy` is authenticated. (It will return 404 instead of asking for a login.) 7. Update docker image to `docker.gitea.com/gitea:1.22`. 8. Restart `docker-compose`. 9. Clear login data in the browser. 10. Open <http://localhost:4180>. 11. Every authentication attempt will result in the error `{"error":"unauthorized_client","error_description":"failed PKCE code challenge"}`. I first encountered the error after a custom application stopped working after updating Gitea but tried to reproduce it with a more mature implementation. ### Gitea Version v1.22 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? `docker-compose` ### Database MySQL/MariaDB
GiteaMirror added the type/bug label 2025-11-02 11:08:28 -06:00
GiteaMirror commented 2025-11-02 11:08:30 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Mar 21, 2025):

Thank you for the detailed steps! At the moment, I can't reproduce it with 1.22 & 1.23:

My steps:

  1. Follow your steps to setup 1.21, see 404 on oauth2 proxy side
  2. Follow your steps to update docker image to 1.22 & 1.23, open a incognito windows, still could see 404 on oauth2 proxy side

Image

Image

Image

@wxiaoguang commented on GitHub (Mar 21, 2025): Thank you for the detailed steps! At the moment, I can't reproduce it with 1.22 & 1.23: My steps: 1. Follow your steps to setup 1.21, see 404 on oauth2 proxy side 2. Follow your steps to update docker image to 1.22 & 1.23, open a incognito windows, still could see 404 on oauth2 proxy side <details> ![Image](https://github.com/user-attachments/assets/5d5deb4e-41c7-408c-8006-6fa7d9316a58) ![Image](https://github.com/user-attachments/assets/ce3d1a22-0bb4-4279-b906-854cf1ac9c18) ![Image](https://github.com/user-attachments/assets/b860c8ec-894c-44c2-be1d-ef515944bbcd) </details>
GiteaMirror commented 2025-11-02 11:08:30 -06:00
Author
Owner
Copy Link

@schnusch commented on GitHub (Mar 21, 2025):

It only is broken for public clients, "Confidential Client." must not be ticked for the application in Gitea. I amended it in the steps as well.

@schnusch commented on GitHub (Mar 21, 2025): It only is broken for public clients, "Confidential Client." must not be ticked for the application in Gitea. I amended it in the steps as well.
GiteaMirror commented 2025-11-02 11:08:30 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Mar 21, 2025):

It seems to be a longstanding bug in Integrate OAuth2 Provider (#5378)

@wxiaoguang commented on GitHub (Mar 21, 2025): It seems to be a longstanding bug in Integrate OAuth2 Provider (#5378) * https://github.com/go-gitea/gitea/pull/5378/files#r2007340187
GiteaMirror commented 2025-11-02 11:08:30 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Mar 21, 2025):

Will be fixed by 33961 and 33962

@wxiaoguang commented on GitHub (Mar 21, 2025): Will be fixed by 33961 and 33962
GiteaMirror commented 2025-11-02 11:08:31 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Mar 21, 2025):

1.23-nightly has been released, the problem should have been fixed, please take a try

@wxiaoguang commented on GitHub (Mar 21, 2025): 1.23-nightly has been released, the problem should have been fixed, please take a try * https://dl.gitea.com/gitea/1.23-nightly/ * https://hub.docker.com/r/gitea/gitea/tags?name=1.23-nightly
GiteaMirror commented 2025-11-02 11:08:31 -06:00
Author
Owner
Copy Link

@schnusch commented on GitHub (Mar 21, 2025):

docker.gitea.com/gitea:1.23-nightly (0f1e0cc8b0c1) seems to work! (Although now I'm not sure how it ever worked in the first place.)

@schnusch commented on GitHub (Mar 21, 2025): `docker.gitea.com/gitea:1.23-nightly` (`0f1e0cc8b0c1`) seems to work! (Although now I'm not sure how it [ever worked](https://github.com/go-gitea/gitea/pull/5378/files#r2007340187) in the first place.)
GiteaMirror commented 2025-11-02 11:08:31 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Mar 22, 2025):

I guess some old code wasn't really executed or something wrong+wrong make the result right.

Anyway, now it works 😄

@wxiaoguang commented on GitHub (Mar 22, 2025): I guess some old code wasn't really executed or something wrong+wrong make the result right. Anyway, now it works 😄
GiteaMirror commented 2025-11-02 11:08:31 -06:00
Author
Owner
Copy Link

@schnusch commented on GitHub (Mar 22, 2025):

I implemented code_challenge_method=S256 in my custom application and S256 worked all along. If $OAUTH2_PROXY_CODE_CHALLENGE_METHOD is set to S256 it works with v1.22+ as well.

@schnusch commented on GitHub (Mar 22, 2025): I implemented `code_challenge_method=S256` in my custom application and `S256` worked all along. If `$OAUTH2_PROXY_CODE_CHALLENGE_METHOD` is set to `S256` it works with v1.22+ as well.
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 type/bug
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#14282
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?