github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-07-21 04:02:17 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

OAuth2 login broken for new users #7746

New Issue
Closed
opened 2025-11-02 07:35:15 -06:00 by GiteaMirror · 11 comments
GiteaMirror commented 2025-11-02 07:35:15 -06:00
Owner
Copy Link
Copy Source

Originally created by @sanderfoobar on GitHub (Aug 24, 2021).

information

  • Gitea version: d22cb600edc2605bd8be25c9079a5ce2c6643547 (recent master i think)
  • Git version: 2.25.1
  • Operating system: Ubuntu 20
  • Built Gitea myself
  • PostgreSQL

description

  1. User goes to my.domain.com (gitea)
  2. User goes to sign-in -> Sign in with OpenID
  3. Redirection to my SSO OpenID provider login.my.domain.com (keycloak)
  4. User creates a new account there
  5. User redirects back to Gitea
  6. Gitea displays a 500 error. (it cannot create the new user in the gitea database?)

This flow used to work on Gitea 1.13. The (new) gitea user would get a "registration screen" upon redirection from SSO. I recently upgraded to 1.14 and it broke. Today I "upgraded" to 1.15 and that also does not work.

The error from logs:

2021/08/24 15:57:40 ...s/context/context.go:700:1() [D] Session ID: 07facb24e44a0b6e
2021/08/24 15:57:40 ...s/context/context.go:701:1() [D] CSRF Token: fhpt1QEoeMpuc98jIfFK82X-B2o6MTYyOTgxNzI1NzE2NzczMDU2Ng
2021/08/24 15:57:40 models/oauth2.go:19:GetActiveOAuth2LoginSourceByName() [I] [SQL] SELECT "id", "type", "name", "is_active", "is_sync_enabled", "cfg", "created_unix", "updated_unix" FROM "login_source" WHERE (name = $1 and type = $2 and is_active = $3) LIMIT 1 [gitea OAuth2 true] - 767.331µs
2021/08/24 15:57:40 ...ers/web/user/auth.go:616:SignInOAuthCallback() [E] UserSignIn: could not find a matching session for this request
2021/08/24 15:57:40 ...s/context/context.go:184:HTML() [D] Template: status/500

The error is: UserSignIn: could not find a matching session for this request.

Which is this bit of code:

https://github.com/markbates/goth/blob/716f16114cccbcbb9ae15099ec2ffa3b006e43eb/gothic/gothic.go#L321-L331

Here is my (truncated) config:

[service]
REGISTER_EMAIL_CONFIRM            = false

[openid]
ENABLE_OPENID_SIGNIN = false
ENABLE_OPENID_SIGNUP = false

[cache]
ADAPTER  = redis
HOST  = [redacted]

[session]
PROVIDER = file
DOMAIN = my.domain.com
SAME_SITE = none

[oauth2]
JWT_SECRET = [redacted]

[oauth2_client]
ENABLE_AUTO_REGISTRATION = true
USERNAME = userid
ACCOUNT_LINKING = auto

[security]
SECRET_KEY     = [redacted]
INTERNAL_TOKEN = [redacted]
Originally created by @sanderfoobar on GitHub (Aug 24, 2021). ## information - Gitea version: `d22cb600edc2605bd8be25c9079a5ce2c6643547` (recent master i think) - Git version: 2.25.1 - Operating system: Ubuntu 20 - Built Gitea myself - PostgreSQL ## description 1. User goes to `my.domain.com` (gitea) 2. User goes to sign-in -> Sign in with OpenID 3. Redirection to my SSO OpenID provider `login.my.domain.com` (keycloak) 4. User creates a new account there 5. User redirects back to Gitea 6. Gitea displays a 500 error. (it cannot create the new user in the gitea database?) This flow used to work on Gitea `1.13`. The (new) gitea user would get a "registration screen" upon redirection from SSO. I recently upgraded to `1.14` and it broke. Today I "upgraded" to `1.15` and that also does not work. The error from logs: ```text 2021/08/24 15:57:40 ...s/context/context.go:700:1() [D] Session ID: 07facb24e44a0b6e 2021/08/24 15:57:40 ...s/context/context.go:701:1() [D] CSRF Token: fhpt1QEoeMpuc98jIfFK82X-B2o6MTYyOTgxNzI1NzE2NzczMDU2Ng 2021/08/24 15:57:40 models/oauth2.go:19:GetActiveOAuth2LoginSourceByName() [I] [SQL] SELECT "id", "type", "name", "is_active", "is_sync_enabled", "cfg", "created_unix", "updated_unix" FROM "login_source" WHERE (name = $1 and type = $2 and is_active = $3) LIMIT 1 [gitea OAuth2 true] - 767.331µs 2021/08/24 15:57:40 ...ers/web/user/auth.go:616:SignInOAuthCallback() [E] UserSignIn: could not find a matching session for this request 2021/08/24 15:57:40 ...s/context/context.go:184:HTML() [D] Template: status/500 ``` The error is: `UserSignIn: could not find a matching session for this request`. Which is this bit of code: https://github.com/markbates/goth/blob/716f16114cccbcbb9ae15099ec2ffa3b006e43eb/gothic/gothic.go#L321-L331 Here is my (truncated) config: ```text [service] REGISTER_EMAIL_CONFIRM = false [openid] ENABLE_OPENID_SIGNIN = false ENABLE_OPENID_SIGNUP = false [cache] ADAPTER = redis HOST = [redacted] [session] PROVIDER = file DOMAIN = my.domain.com SAME_SITE = none [oauth2] JWT_SECRET = [redacted] [oauth2_client] ENABLE_AUTO_REGISTRATION = true USERNAME = userid ACCOUNT_LINKING = auto [security] SECRET_KEY = [redacted] INTERNAL_TOKEN = [redacted] ```
GiteaMirror commented 2025-11-02 07:35:16 -06:00
Author
Owner
Copy Link
Copy Source

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

What is your oauth2 type? This works for Github.

@zeripath commented on GitHub (Aug 26, 2021): What is your oauth2 type? This works for Github.
GiteaMirror commented 2025-11-02 07:35:16 -06:00
Author
Owner
Copy Link
Copy Source

@sanderfoobar commented on GitHub (Aug 26, 2021):

OpenID Connect, the confidential access flow.

@sanderfoobar commented on GitHub (Aug 26, 2021): OpenID Connect, the confidential access flow.
GiteaMirror commented 2025-11-02 07:35:16 -06:00
Author
Owner
Copy Link
Copy Source

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

Did you do a dump and restore? Or just plainly migrate your db?

@zeripath commented on GitHub (Aug 26, 2021): Did you do a dump and restore? Or just plainly migrate your db?
GiteaMirror commented 2025-11-02 07:35:16 -06:00
Author
Owner
Copy Link
Copy Source

@lunny commented on GitHub (Aug 27, 2021):

Please try serval times, this maybe a known issue.

@lunny commented on GitHub (Aug 27, 2021): Please try serval times, this maybe a known issue.
GiteaMirror commented 2025-11-02 07:35:17 -06:00
Author
Owner
Copy Link
Copy Source

@sanderfoobar commented on GitHub (Aug 27, 2021):

Did you do a dump and restore? Or just plainly migrate your db?

How I update between gitea versions:

git fetch -a
git checkout v1.14    (or master)
TAGS="bindata" make build
./gitea web

So I'm not doing any database migration, not sure if it is necessary? I assumed gitea does so automatically. If I try to go back in versions (From master to v1.14.0) I get this error:

Downgrading database version from '192' to '178' is not supported and may result in loss of data integrity.
If you really know what you're doing, execute `UPDATE version SET version=178 WHERE id=1;`

Please try serval times, this maybe a known issue.

Login will not work. See steps above of what happens.

@sanderfoobar commented on GitHub (Aug 27, 2021): > Did you do a dump and restore? Or just plainly migrate your db? How I update between gitea versions: ``` git fetch -a git checkout v1.14 (or master) TAGS="bindata" make build ./gitea web ``` So I'm not doing any database migration, not sure if it is necessary? I assumed gitea does so automatically. If I try to go back in versions (From `master` to `v1.14.0`) I get this error: ```text Downgrading database version from '192' to '178' is not supported and may result in loss of data integrity. If you really know what you're doing, execute `UPDATE version SET version=178 WHERE id=1;` ``` > Please try serval times, this maybe a known issue. Login will not work. See steps above of what happens.
GiteaMirror commented 2025-11-02 07:35:17 -06:00
Author
Owner
Copy Link
Copy Source

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

OK so it was just a plain automatic migration.

Can you confirm on the administrator authentication sources pages that the source has the correct details?

@zeripath commented on GitHub (Aug 27, 2021): OK so it was just a plain automatic migration. Can you confirm on the administrator authentication sources pages that the source has the correct details?
GiteaMirror commented 2025-11-02 07:35:17 -06:00
Author
Owner
Copy Link
Copy Source

@sanderfoobar commented on GitHub (Aug 27, 2021):

In the administration panel it has the correct authentication source details:

  • Authentication Type: OAuth2
  • OAuth2 Provider: OpenID Connect
  • Client ID: gitea
  • Client Secret: redacted
  • OpenID Connect Auto Discovery URL: https://login.my.domain.com/auth/realms/master/.well-known/openid-configuration

When I login with my own (admin) account, I am using the OIDC provider to login, so login for existing users works, just the creation of new user accounts does not (that are created at the Authentication Source).

I am not a Go programmer but I will try to debug a bit now.

@sanderfoobar commented on GitHub (Aug 27, 2021): In the administration panel it has the correct authentication source details: - Authentication Type: `OAuth2 ` - OAuth2 Provider: `OpenID Connect` - Client ID: `gitea` - Client Secret: `redacted` - OpenID Connect Auto Discovery URL: `https://login.my.domain.com/auth/realms/master/.well-known/openid-configuration` When I login with my own (admin) account, I am using the OIDC provider to login, so login for existing users works, just the creation of new user accounts does not (that are created at the Authentication Source). I am not a Go programmer but I will try to debug a bit now.
GiteaMirror commented 2025-11-02 07:35:17 -06:00
Author
Owner
Copy Link
Copy Source

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

OK so we login correctly if the user exists. That's good because it indicates that it's not necessarily something that's broken by the recent changes.

I'm guess I'm just not certain what to do to work this out.

My suspicion is that the problem is going to be related to the cookies. We currently don't provide way to set the cookie configuration but I'm just not sure if that's the problem.

Unfortunately this means we're going to have to add some logging into this area of code to debug this tightly.

@zeripath commented on GitHub (Aug 27, 2021): OK so we login correctly if the user exists. That's good because it indicates that it's not necessarily something that's broken by the recent changes. I'm guess I'm just not certain what to do to work this out. My suspicion is that the problem is going to be related to the cookies. We currently don't provide way to set the cookie configuration but I'm just not sure if that's the problem. Unfortunately this means we're going to have to add some logging into this area of code to debug this tightly.
GiteaMirror commented 2025-11-02 07:35:18 -06:00
Author
Owner
Copy Link
Copy Source

@sanderfoobar commented on GitHub (Aug 27, 2021):

Ok, seems I had 3 issues:

  • The UserSignIn: could not find a matching session for this request error, like @lunny mentioned, can be fixed by clicking on OpenID login twice (first time there is the error, second time it works).
  • My OpenID provider (Keycloak) did not provide the email claim, I had to manually add it so it is included when /token is called. By default the OIDC /userinfo endpoint is not reachable for Gitea (I think) because Gitea only asks for the openid scope when redirecting to Keycloak so it can never get the email.
  • My [oauth2_client] configuration in app.ini needed some modifications

And yes, the UserSignIn: could not find a matching session for this request error is still an issue but is easily fixed for my users (ill tell them to login multiple times).

thanks for the help

@sanderfoobar commented on GitHub (Aug 27, 2021): Ok, seems I had 3 issues: - The `UserSignIn: could not find a matching session for this request` error, like @lunny mentioned, can be fixed by clicking on OpenID login twice (first time there is the error, second time it works). - My OpenID provider (Keycloak) did not provide the `email` claim, I had to manually add it so it is included when `/token` is called. By default the OIDC `/userinfo` endpoint is not reachable for Gitea (I think) because Gitea only asks for the `openid` scope when redirecting to Keycloak so it can never get the email. - My `[oauth2_client]` configuration in `app.ini` needed some modifications And yes, the `UserSignIn: could not find a matching session for this request` error is still an issue but is easily fixed for my users (ill tell them to login multiple times). thanks for the help
GiteaMirror commented 2025-11-02 07:35:18 -06:00
Author
Owner
Copy Link
Copy Source

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

  • My OpenID provider (Keycloak) did not provide the email claim, I had to manually add it so it is included when /token is called. By default the OIDC /userinfo endpoint is not reachable for Gitea (I think) because Gitea only asks for the openid scope when redirecting to Keycloak so it can never get the email.

In terms of scopes requested you can set the OPENID_CONNECT_SCOPES to ask for additional scopes and my pr #16766 will allow you set this on a per source level.

In terms of userinfo I'll have a look at this and see what info we get back from openid

  • My [oauth2_client] configuration in app.ini needed some modifications

What were these?

  • The UserSignIn: could not find a matching session for this request error, like @lunny mentioned, can be fixed by clicking on OpenID login twice (first time there is the error, second time it works).

I'm still kinda confused by what could be causing this. Maybe we just need to redirect back if we fail.

I do think we need to sort something out regarding the cookie though as I think it's a potentially a serious issue.

@zeripath commented on GitHub (Aug 27, 2021): > * My OpenID provider (Keycloak) did not provide the `email` claim, I had to manually add it so it is included when `/token` is called. By default the OIDC `/userinfo` endpoint is not reachable for Gitea (I think) because Gitea only asks for the `openid` scope when redirecting to Keycloak so it can never get the email. In terms of scopes requested you can set the OPENID_CONNECT_SCOPES to ask for additional scopes and my pr #16766 will allow you set this on a per source level. In terms of userinfo I'll have a look at this and see what info we get back from openid > * My `[oauth2_client]` configuration in `app.ini` needed some modifications What were these? > * The `UserSignIn: could not find a matching session for this request` error, like @lunny mentioned, can be fixed by clicking on OpenID login twice (first time there is the error, second time it works). I'm still kinda confused by what could be causing this. Maybe we just need to redirect back if we fail. I do think we need to sort something out regarding the cookie though as I think it's a potentially a serious issue.
GiteaMirror commented 2025-11-02 07:35:18 -06:00
Author
Owner
Copy Link
Copy Source

@sanderfoobar commented on GitHub (Aug 28, 2021):

What were these?

Changed it to this:

[oauth2_client]
OPENID_CONNECT_SCOPES = openid
ENABLE_AUTO_REGISTRATION = false
USERNAME = nickname
ACCOUNT_LINKING = auto

Previously I had USERNAME = userid which uses the sub claim, which is a UUIDv4, which doesn't make for nice usernames ;)

I'm still kinda confused by what could be causing this. Maybe we just need to redirect back if we fail.

No idea, but surely it must be something regarding how Gitea uses Goth (goth stores stuff in the session)

@sanderfoobar commented on GitHub (Aug 28, 2021): > What were these? Changed it to this: ```text [oauth2_client] OPENID_CONNECT_SCOPES = openid ENABLE_AUTO_REGISTRATION = false USERNAME = nickname ACCOUNT_LINKING = auto ``` Previously I had `USERNAME = userid` which uses the `sub` claim, which is a UUIDv4, which doesn't make for nice usernames ;) > I'm still kinda confused by what could be causing this. Maybe we just need to redirect back if we fail. No idea, but surely it must be something regarding how Gitea uses Goth (goth stores stuff in the session)
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 labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#7746