Gitea doesn't send client_id anymore to OIDC server (since 1.7.x) #5925

Closed dani closed 3 years ago

Gitea version (or commit ref): 1.7.1
Git version: 2.12.2
Operating system: CentOS 7
Database (use [x]):
- [ ] PostgreSQL
- [x] MySQL
- [] MSSQL
- [ ] SQLite
Can you reproduce the bug at https://try.gitea.io:
- [ ] Yes (provide example URL)
- [ ] No
- [x] Not relevant
Log gist: https://gist.github.com/dani/b0eaa29526656bf8c65de9d7047d05f7

Description

I've configured 2 auth sources, one is against AD, the other is other is an OpenIDConnect server. My OpenIDConnect server is Lemonldap::NG (probably irrelevant). This was working fine in the 1.6.x branch, but since 1.7.0 (and still present in 1.7.1) I get a 500 error when I try to login using OpenIDConnect. AD auth is still working. Haven't changed anything on the OpenIDConnect server, and reverting to 1.6.x makes OpenIDConnect working again

...

I've had the same error as well. Can sign up via OIDC initially but can't login with it, just get 500 errors, have to revert to using the local login (which is what I've been doing though I would prefer to just click to login via OIDC).

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

Can you show also errors from gitea.log?

I log to the console, which is catched by the Journal. And the logs in Debug mode are

avril 08 09:45:43 gitea gitea[10947]: [Macaron] 2019-04-08 09:45:43: Started GET /user/oauth2/fws_sso for 192.168.7.101
avril 08 09:45:43 gitea gitea[10947]: 2019/04/08 09:45:43 [D] Session ID: 734c139602b64b18
avril 08 09:45:43 gitea gitea[10947]: 2019/04/08 09:45:43 [D] CSRF Token: D_5TTBwfr45JAKXc4BP9RjLIvEA6MTU1NDcwOTA5ODE2MDIyNDk4MQ==
avril 08 09:45:43 gitea gitea[10947]: [Macaron] 2019-04-08 09:45:43: Completed GET /user/oauth2/fws_sso 307 Temporary Redirect in 23.831171ms
avril 08 09:45:44 gitea gitea[10947]: [Macaron] 2019-04-08 09:45:44: Started GET /user/oauth2/fws_sso/callback?session_state=YojjpWgOrArb0waW4Z1yPTq8%2B6lMsYcMrF%2BfU0wi8vU%3D.L3JRZEZINGpPenI4TkhlUjJmQXljdz09&state=ef17065a-c8a1-48b6-8d2d-e62183c90ca5&code=096aec2d81eb17f94344c94832e5a6656333fcf9b109b1c7797171bd81fa31de for 192.168.7.101
avril 08 09:45:44 gitea gitea[10947]: 2019/04/08 09:45:44 [D] Session ID: 734c139602b64b18
avril 08 09:45:44 gitea gitea[10947]: 2019/04/08 09:45:44 [D] CSRF Token: D_5TTBwfr45JAKXc4BP9RjLIvEA6MTU1NDcwOTA5ODE2MDIyNDk4MQ==
avril 08 09:45:44 gitea gitea[10947]: 2019/04/08 09:45:44 [...routers/user/auth.go:561 handleOAuth2SignIn()] [E] UserSignIn: oauth2: cannot fetch token: 500 Internal Server Error
avril 08 09:45:44 gitea gitea[10947]: Response: Internal Server Error
avril 08 09:45:44 gitea gitea[10947]: 2019/04/08 09:45:44 [D] Template: status/500
avril 08 09:45:44 gitea gitea[10947]: [Macaron] 2019-04-08 09:45:44: Completed GET /user/oauth2/fws_sso/callback?session_state=YojjpWgOrArb0waW4Z1yPTq8%2B6lMsYcMrF%2BfU0wi8vU%3D.L3JRZEZINGpPenI4TkhlUjJmQXljdz09&state=ef17065a-c8a1-48b6-8d2d-e62183c90ca5&code=096aec2d81eb17f94344c94832e5a6656333fcf9b109b1c7797171bd81fa31de 404 Not Found in 19.520431ms

Which is more or less the same as the initial report https://gist.github.com/dani/b0eaa29526656bf8c65de9d7047d05f7

This is with Gitea 1.7.5

No this from gitea stdout. Check gitea logs directory for file gitea.log there should be more detailed error information

After enabling file logging (I was logging only to the console), and setting all the LEVELS to Debug, I do have a gitea.log. But it doesn't contains more info :

2019/04/08 10:37:09 [D] CSRF Token: Uz5-7IsizTOxW5ULjHKKjevHUcw6MTU1NDcxMjAyODAyMjQ4NjY2Ng==
2019/04/08 10:37:09 [...routers/user/auth.go:561 handleOAuth2SignIn()] [E] UserSignIn: oauth2: cannot fetch token: 500 Internal Server Error
Response: Internal Server Error
2019/04/08 10:37:09 [D] Template: status/500
2019/04/08 10:37:10 [D] Session ID: 734c139602b64b18
2019/04/08 10:37:10 [D] CSRF Token: Uz5-7IsizTOxW5ULjHKKjevHUcw6MTU1NDcxMjAyODAyMjQ4NjY2Ng==

Maybe I'm missing a configuration param ?

do you have correct oauth server URL in auth source? can you try curl -vvv https://oauth.sever/url from server shell?

Yes, I have set the correct URL in auth source. This setup is working in 1.6.4 (including if I revert to gitea 1.6.x). Here's the output :

[root@gitea ~]# curl -vvv https://sso.fws.fr/.well-known/openid-configuration
* About to connect() to proxy proxyout.fws.fr port 3128 (#0)
*   Trying 10.29.1.11...
* Connected to proxyout.fws.fr (10.29.1.11) port 3128 (#0)
* Establish HTTP proxy tunnel to sso.fws.fr:443
> CONNECT sso.fws.fr:443 HTTP/1.1
> Host: sso.fws.fr:443
> User-Agent: curl/7.29.0
> Proxy-Connection: Keep-Alive
> 
< HTTP/1.1 200 Connection established
< 
* Proxy replied OK to CONNECT request
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
*       subject: CN=sso.fws.fr
*       start date: mars 14 01:13:23 2019 GMT
*       expire date: juin 12 01:13:23 2019 GMT
*       common name: sso.fws.fr
*       issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US
> GET /.well-known/openid-configuration HTTP/1.1
> User-Agent: curl/7.29.0
> Host: sso.fws.fr
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx
< Date: Mon, 08 Apr 2019 08:47:39 GMT
< Content-Type: application/json; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Encoding
< Expires: Thu, 01 Jan 1970 00:00:01 GMT
< Cache-Control: no-cache
< Cache-Control: no-cache, no-store, private
< 
{"userinfo_signing_alg_values_supported":["none","HS256","HS384","HS512","RS256","RS384","RS512"],"frontchannel_logout_supported":true,"authorization_endpoint":"https://sso.fws.fr/oauth2/authorize","claims_supported":["sub","iss","auth_time","acr"],"frontchannel_logout_session_supported":true,"grant_types_supported":["authorization_code","implicit","hybrid"],"issuer":"https://sso.fws.fr","backchannel_logout_session_supported":true,"id_token_signing_alg_values_supported":["none","HS256","HS384","HS512","RS256","RS384","RS512"],"require_request_uri_registration":false,"request_parameter_supported":true,"request_uri_parameter_supported":true,"token_endpoint":"https://sso.fws.fr/oauth2/token","end_session_endpoint":"https://sso.fws.fr/oauth2/logout","response_types_supported":["code","id_token","id_token token","code id_token","code token","code id_token token"],"subject_types_supported":["public"],"token_endpoint_auth_methods_supported":["client_secret_post","client_secret_basic"],"jwks_uri":"https://sso.fws.fr/* Connection #0 to host proxyout.fws.fr left intact
oauth2/jwks","userinfo_endpoint":"https://sso.fws.fr/oauth2/userinfo","backchannel_logout_supported":true,"scopes_supported":["openid","profile","email","address","phone"],"acr_values_supported":[],"check_session_iframe":"https://sso.fws.fr/oauth2/checksession"}

How you have configured it in gitea?

oidc_gitea

The secret is correct (and contains only alpha num chars, + and / if it matters)

Check that you have correctly set client ID and client secret

Already checked. And, as it's working in 1.6.4, it's correct

One other detail : in my environment, gitea server must use an outbound HTTP proxy to reach its OIDC server. It's configured through the HTTP_PROXY/HTTPS_PROXY env var

Do you have it set in service file?

I have it set globaly at systemd level (/etc/systemd/system.conf.d/proxy.conf), and gitea is started by a systemd unit. My service unit for gitea is like this :

[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target

[Service]
LimitNOFILE=65535
Type=simple
User=gitea
Group=gitea
WorkingDirectory=/opt/gitea
ExecStart=/bin/scl enable sclo-git212 -- /opt/gitea/bin/gitea web -c /opt/gitea/etc/app.ini
Restart=always
Environment=USER=gitea HOME=/opt/gitea GITEA_WORK_DIR=/opt/gitea
PrivateTmp=yes
PrivateDevices=yes
ProtectSystem=full
ProtectHome=yes
NoNewPrivileges=yes
MemoryLimit=1024M
SyslogIdentifier=gitea
StartLimitInterval=0
RestartSec=10

[Install]
WantedBy=multi-user.target

Note that the request (from gitea to OIDC) is not simply ignoring the proxy, it's not sent at all (checked with tcpdump). So, maybe the proxy stuff is not relevant.

Still the same with Gitea 1.8.1. OIDC can't be used. As soon as I click the OIDC button on login page, I get the err 500 page. So, I debugged this a bit further, comparing the request sent from Gitea to the OIDC server between gitea 1.6.4 (last version working) and 1.8.1. The request is in fact correctly sent (not sure why I missed it previously). And here are the result :

With 1.6.4

client_id=gitea&code=XXXXX&grant_type=authorization_code&redirect_uri=https%3A%2F%2Fgit.fws.fr%2Fuser%2Foauth2%2Ffws_sso%2Fcallback&scope=openid

With 1.8.1

code=XXXXX&grant_type=authorization_code&redirect_uri=https%3A%2F%2Fgit.fws.fr%2Fuser%2Foauth2%2Ffws_sso%2Fcallback

So, the problem seems to be that gitea is not sending client_id anymore in its request. There's also scope=openid missing (but I don't know if it's really needed)

I have confirmed missing client_id and scope=openid for v1.8.1 and that those fields are not sent in v1.6.4 in the reply. My provider is keycloak.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

Please don't close this. The issue is still present in latest 1.8.x. client_id is not sent to the OIDC server since 1.7.0, only the secret is sent (code=XXX), which alone, is useless to the OIDC server

Is this still an issue?

not entirely sure if this is my misconfiguration but gitea login to concourse ci using both oauth and oidc still fails...

In my case it was some special characters in the OIDC secret which prevented it from working. Changing the secret to some long, random string, but only containing alpha/num chars fixed it.

not entirely sure if this is my misconfiguration but gitea login to concourse ci using both oauth and oidc still fails...

Are you able to debug any further?

Are you able to debug any further?

will attempt to tomorrow and try to report back but preliminary attribution goes to misconfiguration on my side. edit: couldn't find time to get back to this yet but I have it in mind...

I'm going to close this. Please open another issue with logs and further details if it recurs

go-gitea / gitea

Gitea doesn't send client_id anymore to OIDC server (since 1.7.x) #5925

Description