OpenID redirect loop

[otbutz]

Description

I'm using gitea as an OpenID provider for Jenkins. Everything works as long as the user is already logged into gitea. If there's no valid Jenkins/gitea session, the user is properly guided to the gitea login page. The problem starts after hitting the Login button:

The initial POST request to /user/login contains the username and password entered in the login form. The server answers with a HTTP 303 status code and the location /login/oauth/authorize with a few query parameters. The redirect_uri parameter of this request points to my Jenkins instance: https://jenkins.mydomain.com/securityRealm/finishLogin

The problem is that this ends up in a redirect loop as /login/oauth/authorize will also answer with HTTP 303 pointing to /user/login. Firefox ultimately errors out with a NS_ERROR_REDIRECT_LOOP.

The authentication itself works though. I can successfully open gitea or jenkins afterwards with a valid user session.

The configuration in Jenkins is pretty barebones:

Gitea Version

1.20.1

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?

Binary started via systemd behind a caddy reverse proxy.

Database

PostgreSQL

[otbutz]

The chain of requests from jenkins to the initial gitea login page:

[otbutz]

The strange thing is the cookie set by the first call to login/oauth/authorize:

redirect_to=%2Flogin%2Foauth%2Fauthorize%3Fclient_id%3DXXXXXXXXXXXXXXXXXXXXXX20%26redirect_uri%3Dhttps%3A%2F%2Fjenkins.mydomain.com%2FsecurityRealm%2FfinishLogin%26response_type%3Dcode%26scope%3Dopenid%2520profile%2520groups%2520email%26state%3Dxxxxxxxxxxxxxxxxxx%26nonce%3Dxxxxxxxxxxxxxxxxxxxxx; Path=/; HttpOnly; Secure; SameSite=Lax

A redirect to a redirect?

[evgnblkn]

I have the same problem. PgAdmin works well with the Gitea oauth provider, but Portainer and my own application are constantly getting to the login page. This has been around since version 1.19. Perhaps this is related to #20908 and #24767.

[MrGussio]

Same thing happened for a colleague of mine this morning. Interesting enough, for me personally it does work, but unlike my colleague I have 2FA enabled, so I first see that page, and then the redirect does work correctly.

[evgnblkn]

I have the same problem. PgAdmin works well with the Gitea oauth provider, but Portainer and my own application are constantly getting to the login page. This has been around since version 1.19. Perhaps this is related to #20908 and #24767.

We found the cause of the loop, the redirect_uri parameter was not specified in the URL-encoded format. It might help in other cases too.

[m42e]

@evgnblkn how did you solve it then?

[ChenXiaoTemp]

Is there any solution?

[jimafisk]

We're having the same issue using Gitea as an OAuth provider for our static websites (using https://plenti.co/).

Everything works as long as the user is already logged into gitea

If there is already an active login directly to Gitea, it works for us as well.

If there's no valid Jenkins/gitea session, the user is properly guided to the gitea login page. The problem starts after hitting the Login button

Same, the login page just refreshes when clicking "Sign in" and it 303s in the console.

This has been around since version 1.19

We noticed something similar, it used to work in prior versions but somewhere around this version (we're not sure exactly when), we started having this issue.

[jimafisk]

We found the cause of the loop, the redirect_uri parameter was not specified in the URL-encoded format.

Using encodeURIComponent() ended up working for us too.

Broken:

const url = authProvider.authUrl + env.cms.redirectUrl;
window.open(url, "_self", "");

Working:

const url = authProvider.authUrl + encodeURIComponent(env.cms.redirectUrl);
window.open(url, "_self", "");

[wxiaoguang]

@jimafisk thank you very much for the hint!

@otbutz could you confirm that it is the same problem? The "redirect_uri" isn't URL-encoded in your screenshot either.

[otbutz]

Just to confirm but the redirect_uri should be stored as e.g https%3A%2F%2Fjenkins.example.com%2FsecurityRealm%2FfinishLogin ?

At least the builtin applications don't follow that either:

gitea/models/auth/oauth2.go

Lines 59 to 73 in 5e72526

	m["a4792ccc-144e-407e-86c9-5e7d8d9c3269"] = &BuiltinOAuth2Application{
	ConfigName: "git-credential-oauth",
	DisplayName: "git-credential-oauth",
	RedirectURIs: []string{"http://127.0.0.1", "https://127.0.0.1"},
	}
	m["e90ee53c-94e2-48ac-9358-a874fb9e0662"] = &BuiltinOAuth2Application{
	ConfigName: "git-credential-manager",
	DisplayName: "Git Credential Manager",
	RedirectURIs: []string{"http://127.0.0.1", "https://127.0.0.1"},
	}
	m["d57cb8c4-630c-4168-8324-ec79935e18d4"] = &BuiltinOAuth2Application{
	ConfigName: "tea",
	DisplayName: "tea",
	RedirectURIs: []string{"http://127.0.0.1", "https://127.0.0.1"},
	}

[wxiaoguang]

At least the builtin applications don't follow that either:

That's a different problem. For RedirectURIs in code, they should be stored as their raw value. These values should be encoded/decoded when used.

---

For the redirecting problem, I haven't got enough time to get a reproducible setup. So, if there would be a prepared reproducible environment/setup (eg: by docker compose), I could spend time on debugging it.

[Zettat123]

Maybe #28529 is the same issue?

[wxiaoguang]

I think most "redirect loop" problems could be fixed by:

-> Use strict protocol check when redirect #29642

It would be helpful if you could build your own binary to test the patch. Thank you very much.

(or wait for 1.21 nightly, I think it could be ready soon)

[wxiaoguang]

The 1.21 nightly (pre-1.21.8) is ready, it is a stable release and will become 1.21.8 soon. Please take a try, if the problem is still not resolved, please help to provide more details. Thank you!

Get 1.21 nightly:

• Docker: https://hub.docker.com/r/gitea/gitea/tags?page=1&name=nightly
• Binary: https://dl.gitea.com/gitea/1.21/

[otbutz]

I think most "redirect loop" problems could be fixed by:

-> Use strict protocol check when redirect #29642

Confirmed 👍

I just tested the nightly version in a private window by trying to log in to our Jenkins instance. Everything works as expected without any funzies.

[wxiaoguang]

Thank you very much for the confirm. I think this issue could be closed. If there is any new problem, feel free to report 🙏

And sorry for the inconvenience caused by the bug.