Option skip-provider-button provides white page with "Found." link

[markuzzi]

When I use the parameter -skip-provider-button, the login button is not shown anymore, but a white page with a single link named "Found" instead.

Expected Behavior

I would have expected to be redirected to the login site of the provider directly. In addition, the Found link does not work, as it contains a redirect URI with 0.0.0.0 as host name.

Current Behavior

Show white page with "Found" link instead of being redirected to provider.

Steps to Reproduce (for bugs)

I have a docker container (swarm) with the following settings

oauth2:
  image: oauth2_proxy # build from repository (armv6)
  command:
    - -cookie-domain=xxx
    - -cookie-secure=true
    - -cookie-secret=xxx
    - -email-domain=*
    - -http-address=0.0.0.0:4180
    - -pass-access-token
    - -provider=gitlab
    - -gitlab-group=xxx
    - -client-id=xxx
    - -client-secret=xxx
    - -set-authorization-header
    - -set-xauthrequest
    - -whitelist-domain=.${DOMAIN}
    - -footer=-
    - -banner=xxx
    - -provider-display-name=me
    - -skip-provider-button=true

Your Environment

• Version used: latest version (>4.1.0) from git (via git clone)

[github-actions[bot]]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.

[diyfr]

Same issue with prebuilt v5.1.0

[boutobza]

Same issue here, i used docker image quay.io/oauth2-proxy/oauth2-proxy:v7.2.0

@diyfr @markuzzi did you find a solution for this issue ?

[Montralis]

Any Updates on this?

[bakito]

I also get the same page if provider button is skipped.

<a href="https://lemur-1.cloud-iam.com/auth/realms/...">Found</a>.

[tuunit]

@bakito which version of oauth2-proxy are you using? Which IDP and do you have an upstream configured?

[bakito]

@tuunit oauth2-proxy version v7.5.0 with keycloak-oidc provider (same happens with keycloak)

If the provider button is enabled I get the button with 'Sign in with Keycloak OIDC'. If button is enabled I the the Found link, which if clicks forwards me to the provider login page.

I use the following config:

OAUTH2_PROXY_COOKIE_DOMAIN: '.foo.bar'
OAUTH2_PROXY_COOKIE_REFRESH: '12h'
OAUTH2_PROXY_COOKIE_SECURE: 'true'
OAUTH2_PROXY_COOKIE_SECRET: ${OAUTH2_PROXY_COOKIE_SECRET}
OAUTH2_PROXY_EMAIL_DOMAINS: '*'
OAUTH2_PROXY_FOOTER: '-'
OAUTH2_PROXY_HTTP_ADDRESS: '0.0.0.0:4180'
OAUTH2_PROXY_PASS_BASIC_AUTH: 'false'
OAUTH2_PROXY_PASS_USER_HEADERS: 'true'

OAUTH2_PROXY_PROVIDER: 'keycloak-oidc'
OAUTH2_PROXY_CLIENT_ID: ${OAUTH2_PROXY_CLIENT_ID}
OAUTH2_PROXY_CLIENT_SECRET: ${OAUTH2_PROXY_CLIENT_SECRET}
OAUTH2_PROXY_SCOPE: openid

OAUTH2_PROXY_REVERSE_PROXY: 'true'
OAUTH2_PROXY_SET_AUTHORIZATION_HEADER: 'true'
OAUTH2_PROXY_SET_XAUTHREQUEST: 'true'
OAUTH2_PROXY_WHITELIST_DOMAIN: '.foo.bar'
OAUTH2_PROXY_OIDC_ISSUER_URL: ${OAUTH2_PROXY_KEYCLOAK_URL}/auth/realms/foo

[tuunit]

@bakito I'll try to replicate the issue later

[bakito]

What also might be relevant is that I use oauth2-proxy as forward auth traefik middleware.

      traefik.http.middlewares.oauth-verify.forwardAuth.address: http://oauth:4180/oauth2/auth
      traefik.http.middlewares.oauth-verify.forwardAuth.trustForwardHeader: 'true'
      traefik.http.middlewares.oauth-verify.forwardAuth.authResponseHeaders: X-Auth-Request-User,X-Auth-Request-Email,Set-Cookie
      traefik.http.middlewares.oauth-signin.errors.service: 'oauth@docker'
      traefik.http.middlewares.oauth-signin.errors.status: '401'
      traefik.http.middlewares.oauth-signin.errors.query: /oauth2/sign_in

[tuunit]

Okay my first round of testing tells me that the issue is not with oauth2-proxy and most probably not with keycloak.

Most likely a missconfiguration of traefik. Please have a look at the following comment: https://github.com/oauth2-proxy/oauth2-proxy/issues/1639#issuecomment-1686259034

[bakito]

Thank you for the update. indeed it seems to be an issue with traefik forwardAuth. Following this comment https://github.com/oauth2-proxy/oauth2-proxy/issues/1639#issuecomment-1224763241 in the same issue I came a bit further. The forwarding is now working without the link. But callback ends in a 404.

But this is probably also not an issue of oauth2 proxy.

[glikpsc]

I have the same issue there. We are using OKTA as oidc provider. Using oAuth-proxy 7.5.1 as docker. I was trying to play with config but the button is there unless I will not skip the provider button. Otherwise, the process works as I need it to. I looked at the logs of OAuthProxy and could not see anything that gave any clue. If I need to look at the OKTA side I would appreciate any pointers as to where to look. I will work with our sysadmin to make changes there. Thank you in advance

P.S. Wanted to add that use ngnix and issue might be connected that nginx config misses something to make exchange between nginx and oAuth proxy smooth. After all that "Found" button has all info (nothing asked from user) and click on it just makes REST call which can be done in flow automatically. I included relevant nginx location section below.

@bakito I was advised to contact you. Maybe you can spare some time to see what is missing? TIA!

Config is below

  -e OAUTH2_PROXY_CLIENT_ID="xxxxx \
  -e OAUTH2_PROXY_CLIENT_SECRET="xxxxx" \
  -e OAUTH2_PROXY_COOKIE_SECURE=true \
  -e OAUTH2_PROXY_COOKIE_SECRET="xxxxx" \
  -e OAUTH2_PROXY_EMAIL_DOMAINS=* \
  -e OAUTH2_PROXY_ERRORS_TO_INFO_LOG=true \
  -e OAUTH2_PROXY_PROVIDER="oidc" \
  -e OAUTH2_PROXY_REDIRECT_URL="https://myapp.mydomain.net/oauth2/callback" \
  -e OAUTH2_PROXY_OIDC_ISSUER_URL="https://mydomain.okta.com" \
  -p 4180:4180 -p 8080:8080 \
  -e OAUTH2_PROXY_UPSTREAMS="http://myapp.mydomain.net" \ 
  -e OAUTH2_PROXY_COOKIE_HTTPONLY=false \
  -e OAUTH2_PROXY_PASS_USER_HEADERS=true \
  -e OAUTH2_PROXY_SHOW_DEBUG_ON_ERROR=true \
  -e OAUTH2_PROXY_COOKIE_CSRF_PER_REQUEST=true \
  -e OAUTH2_PROXY_SET_XAUTHREQUEST=true \
  -e OAUTH2_PROXY_PASS_ACCESS_TOKEN=true \
  -e OAUTH2_PROXY_SKIP_PROVIDER_BUTTON=true \
  -e OAUTH2_PROXY_APPROVAL_PROMPT="none" \
  -e OAUTH2_PROXY_PASS_BASIC_AUTH="false" \

The button link that appears as

https://mydomain.okta.com/oauth2/v1/authorize?approval_prompt=none&client_id=xxxxx&redirect_uri=https%3A%2F%2Fmyapp.mydomain.net%2Foauth2%2Fcallback&response_type=code&scope=openid+email+profile&state=DB1dO3quF7g33NU670Ba3fV2_yt32plPlx7QVTXyp5A%3A%2F`

       location / {

            auth_request /oauth2/auth;
            auth_request_set $backend_status $upstream_status ;
            error_page 401  /oauth2/sign_in;
.....
}

        #call to backend that authorizes functions of user 
        location /api/user/ {
        auth_request /oauth2/auth ;

        auth_request_set $id $upstream_http_x_auth_request_preferred_username;
            proxy_set_header  My-User $id;
            proxy_pass_header My-User;

            proxy_http_version 1.1;
            proxy_set_header Host $host;
            proxy_pass_request_headers on;
            proxy_pass http://backend;
        }

        location /oauth2/ {
            proxy_pass      http://myapp.mydomain.net:4180/oauth2/;
            proxy_set_header Host                    $host;
            proxy_set_header X-Real-IP               $remote_addr;
            proxy_set_header X-Scheme                $scheme;
        }

        location = /oauth2/auth {
            #return 200 'just came back from oau
            proxy_pass       http://blink-uat.pointstate.net:4180/oauth2/auth;
            proxy_set_header Host             $host;
            proxy_set_header X-Real-IP        $remote_addr;
            proxy_set_header X-Origin-URI     $request_uri;
            proxy_set_header X-Scheme         $scheme;
            # nginx auth_request includes headers but not body
            proxy_set_header Content-Length   "";
            proxy_pass_request_body           off;
        }

[ymuichiro]

The following configuration worked well. I will put it up for reference.

https://github.com/ymuichiro/oauth2-proxy/

[zs-dima]

@ymuichiro thanks for the example, although it still leads to the "Found." link in case of Traefik. Latest oauth2-proxy and dex. Chrome web browser 120.0.6099.72 x64, Windows

[Montralis]

I dont know if i miss something, but have u give a Upstream , a issuer-url and redirect in your configuration? If not, the proxy just dont know where to go, after the init call. Your - -http-address=0.0.0.0:4180 is just for the internal redirect in the oauth2-proxy.

[github-actions[bot]]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.

[zs-dima]

+1 re-activate the issue

[tdudas]

any idea how we can resolve that issue with found link using proxy traefik?

[curlup]

i have the same

[rgarrigue]

I've the same issue with Nginx

[diegopazosrego]

Hi everyone!

I´ve the same issue, can anyone help

Our stack:

• Reverse Nginx Proxy
• Oauth2-proxy

location /oauth2/ {
            proxy_pass http://localhost:4180;
            proxy_pass_request_headers on;
            proxy_pass_request_body on;
            proxy_set_header Host                    $host;
            proxy_set_header X-Real-IP               $remote_addr;
            proxy_set_header X-Auth-Request-Redirect $request_uri;
        }
        location = /oauth2/auth {
            proxy_pass http://localhost:4180;
            proxy_pass_request_headers off;
            proxy_pass_request_body off;
            proxy_set_header Host             $host;
            proxy_set_header X-Real-IP        $remote_addr;
            proxy_set_header X-Forwarded-Uri  $request_uri;
            # nginx auth_request includes headers but not cu
            proxy_set_header Content-Length   "";
        }

        location /oauth/start {
            proxy_pass http://localhost:4180;

[StefanMarkmann]

Hello,

i also encountered this bug in 7.6.0, but managed to find a way around and found a cause in oauth2-proxy and a documentation-flaw.

As no one posted any complete configs, i assume you all followed the docs as i did: https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview

In there we find a location within the server block of the nginx config:

  location / {
    auth_request /oauth2/auth;
    error_page 401 =403 /oauth2/sign_in;

When looking at your browsers network-debugging, you might notice, that the server indeed sent a location-header, but did not relocate the site/tab. This is due to the http-code of 403 which represents an auth-error, not a redirect - which is why in my case firefox did not follow the location-header. Instead the browser stopped and rendered a "Found."-link itself.

Workaround: When changing the 403 to 302 it works as intended:

  location / {
    auth_request /oauth2/auth;
    error_page 401 =302 /oauth2/sign_in;

I did not debug the go code yet, but sending a location-header with other than 30X-code seems wrong. But 401/403 are okay if we present that button on a site. So the behavior should be changed to send 302 instead if OAUTH2_PROXY_SKIP_PROVIDER_BUTTON: "true".

Also the docs might be changed reflecting this.

This might cause issues with the proxied/upstream service, i am looking forward to your experiences.

[col-panic]

For traefik users, there is an open issue that discusses rewriting the status code which could be a solution to this problem https://github.com/traefik/traefik/issues/2039

[curlup]

This approach might work https://github.com/oauth2-proxy/oauth2-proxy/issues/1297#issuecomment-2004788570

[harlemmuniz]

Here the flag skip-provider-button only worked when setting the reverse-proxy flag as true.

[github-actions[bot]]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.