Describe ingress setup for dynamic callback urls

[elsesiy]

Hi @JoelSpeed,

I'm facing the same issue described in #12 and have been trying to get the described setup working but the redirect to the downstream ingress doesn't work. Do you have some more documentation on how this exactly should look like?

Here's what I did:

1. Install the chart

helm install stable/oauth2-proxy --name login-oauth2-proxy \
    --namespace xyz \
    --set config.clientID="clientId" \
    --set config.clientSecret="clientSecret" \
    --set config.cookieSecret="cookieSecret" \
    --set extraArgs.provider="azure" \
    --set extraArgs.azure-tenant="tenantId" \
    --set extraArgs.whitelist-domain=".mydomain.com" \
    --tls

2. Create the ingress for oauth2_proxy:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: login-ingress-oauth2
  namespace: xyz
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - host: login.mydomain.com
    http:
      paths:
      - backend:
          serviceName: login-oauth2-proxy
          servicePort: 80
        path: /oauth2
  tls:
  - hosts:
    - login.mydomain.com

By now browsing https://login.mydomain.com/oauth2/sign_in works as expected.

3. Configure downstream ingress to use the oauth2_proxy:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: myservice-ingress
  namespace: xyz
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/auth-url: "https://login.mydomain.com/oauth2/auth"
    nginx.ingress.kubernetes.io/auth-signin: "https://login.mydomain.com/oauth2/start?rd=service.cdhamap.com"
spec:
  rules:
  - host: service.cdhamap.com
    http:
      paths:
      - backend:
          serviceName: service-backend
          servicePort: 1337
        path: /
  tls:
  - hosts:
    - service.cdhamap.com

Browsing https://service.mydomain.com now correctly redirects me to the Microsoft Login but still shows https://login.mydomain.com/oauth2/callback as the redirect_uri which then after successful authentication falls back to default-backend.

What am I missing?

Thanks a lot!!

[r0fls]

I'm encountering the same problem, after successful oauth2 workflow the final URL is the oauth2-proxy URL, not the kubernetes dashboard ingress (trying to follow: https://thenewstack.io/single-sign-on-for-kubernetes-dashboard-experience/)

[maxh8086]

you need to publish dashboard service on http not on https, this is how it worked for me.. after going through lot of blogs and forum, what i understood is.. oauth2 proxy do not understand how to pass token via header when dashboard is using selfsign certificate... your upstream will be dashboard service url http://kubernetes-dashboard.kube-system.svc.cluster.local.. if you still wish to ssl your dashboard.. you may use san certificate for oauth2 and set them up on ingress level to handle it properly.

[okgolove]

Hello everyone! Have the same idea. I want to have a domain like oauth.example.com, not specified path (/oauth2) for every Ingress I want to auth using oauth.
A scheme is: Kibana (for example) ingress -> Oauth-proxy -> keycloak, successful auth -> oauth-proxy /oauth2/callback and in the end it redirects me to oauth.example.com with 404.

Tried to explore something about X-Auth-Request-Redirect, but it didn't help. The main idea to set up the final redirect to the service requested OAuth in the start (for my case this is Kibana).

[JoelSpeed]

Hi @elsesiy, I've had a look through your config and have two suggestions that might help,

First off, make sure to set your cookie domain, it should be the parent domain off all subdomains you are protecting and I think it needs to include the OAuth2_Proxy as well, are your Authentication and protected service on the same parent domain? (eg foo.bar.example.com and baz.example.com share example.com as a parent so the cookie-domain=.example.com to allow the cookie to be read by them all)

Secondly, in your redirect, try adding the scheme to the beginning of the request, if you are https only then rd=https://$host$request_uri should suffice, else you can try rd=$scheme://$host$request_uri for mixed http/https (I haven't tested the latter btw)

Let me know how you get on! 😄

[elsesiy]

@JoelSpeed Works flawlessly now, thanks. The missing piece was the cookie-domain 👍 Do you think it makes sense to create a dedicated section in the docs on how to set this up?

[JoelSpeed]

Do you think it makes sense to create a dedicated section in the docs on how to set this up?

It really really does, but sadly no one has had time to do so yet

[okgolove]

@elsesiy it would be great, if you were able to describe it!

[maxh8086]

i am also facing same challange, please let me know if there is any way available to add if(condition to ensure authentication is done) { rewrite URL} with below example to solve this

https://kubernetes.github.io/ingress-nginx/examples/rewrite/#examples

rather than nginx sidecar -

https://www.callumpember.com/Kubernetes-A-Single-OAuth2-Proxy-For-Multiple-Ingresses/

    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/auth-url: "https://oauth.domain.com/oauth2/auth"
    nginx.ingress.kubernetes.io/auth-signin: "https://oauth.domain.com/oauth2/start?rd=/redirect/$http_host$request_uri$is_args$args"
    nginx.ingress.kubernetes.io/configuration-snippet: |
      auth_request_set $token $upstream_http_authorization;
      proxy_set_header Authorization $token;
      rewrite /redirect/?(.*) https://$1 break;

This is my non working setting, where i am looking for condition to confirm authentication before redirect. with above setting, it redirect before authentication itself.

Looking for : rewrite if(Authenticated) {/redirect/?(.*) https://$1 break};

[elsesiy]

@JoelSpeed @okgolove OK, I can create a PR. Shall I just add to the README or create a dedicated directory for guides & how-tos?

[elsesiy]

Until @JoelSpeed decides where to contribute, I published a blog post for now.

[samvdb]

@JoelSpeed comment should work for most people. setting cookie-domain does the trick.
One other thing that might be needed (like in my use-case) is the whitelist-domain setting.

eg : whitelist-domain: .example.com

This fixes the invalid redirects after the first login.
example without whitelist-domain:

scenario 1: go to app.example.com without cookies => you will need to login
after login you will be redirected to auth.example.com/callback (or whatever your proxy domain is)
You will get a 404 here.

scenario 2: go to app.example.com with cookies ( you already logged in before )
everything works...

Hi @elsesiy, I've had a look through your config and have two suggestions that might help,

First off, make sure to set your cookie domain, it should be the parent domain off all subdomains you are protecting and I think it needs to include the OAuth2_Proxy as well, are your Authentication and protected service on the same parent domain? (eg foo.bar.example.com and baz.example.com share example.com as a parent so the cookie-domain=.example.com to allow the cookie to be read by them all)

Secondly, in your redirect, try adding the scheme to the beginning of the request, if you are https only then rd=https://$host$request_uri should suffice, else you can try rd=$scheme://$host$request_uri for mixed http/https (I haven't tested the latter btw)

Let me know how you get on!

[beebird]

I added whitelist-domain parameter and everything works as expected!!! I'm so happy:)

[agolomoodysaada]

The suggested solution https://oauth.mywebsite.com/oauth2/start?rd=$scheme://$host$request_uri almost worked for me. The $host resolved to my oauth host instead of the original target host. To make nginx-ingress redirect correctly, I had to use the forwarded host using the $best_http_host variable. For example: rd=$scheme://$best_http_host$request_uri.
The $scheme worked like a charm!

[okgolove]

Did someone try this scheme with Keycloak?

[sc250024]

Also curious if anyone got this working for GitLab? In my case, the redirect to GitLab works fine, but GitLab redirects to the base oauth2_proxy URL (https://oauth2.mycompany.com/) instead of following the redirect rd=https://$host$request_uri part.

Any ideas?

[sc250024]

Nevermind, solved it. It was the whitelist-domain feature :D

[Swetad90]

Does anyone know how to redirect it to a host:port?
For me the redirect is happening only to the host (ie metrics.staging.com) and I want to redirect to metrics.staging.com:9099 ?

My prometheus ingress:
` nginx.ingress.kubernetes.io/auth-signin: https://oauth2-qa.staging.com:9043/oauth2/start?rd=https://$host$request_uri$is_args$args

nginx.ingress.kubernetes.io/auth-url: https://oauth2-qa.staging.com:9043/oauth2/auth
nginx.ingress.kubernetes.io/backend-protocol: HTTPS
`

My whitlist-domain and cookie-domain are both set to .staging.com

[JoelSpeed]

@Swetad90 As far as I'm aware, the code that deals with the whitelists doesn't account for ports, maybe you could submit a PR to add it?

https://github.com/pusher/oauth2_proxy/blob/62bf233682372266e515fa477031c2aba5ff1512/oauthproxy.go#L497-L516

[aseemmishra25]

@JoelSpeed I need a help please.. my oauth2 proxy config looks good, I get the login page , when I try to login it lets me in to the landing page as that is the flow for it but with access request module. My issue is the username I used it comes back appended like this "{Email:username@abc.com}" so my username looks like as if it has "email:" added to it.

[JoelSpeed]

I used it comes back appended like this

How are you retrieving this email from the proxy? There are various ways you can get the information like this out. Also, could you please open a new issue so we don't pollute this one, this seems like a separate problem

[aseemmishra25]

@JoelSpeed I will do the needful, in the mean time is there any best practices I can follow please let me know. We are on a critical path so was asking.. can you please point out what you meant "There are various ways you can get the information like this out".
Please help.

[JoelSpeed]

@aseemmishra25 I was referring more to this comment from yourself

My issue is the username I used it comes back appended like this "{Email:username@abc.com}" so my username looks like as if it has "email:" added to it.

How did you read that value? Was it set in a header? If so which header? Also, does your OAuth2 Proxy directly proxy requests to upstream services or do you use it in the Nginx auth request style deployment?

[messiahUA]

I'm banging my head on this and I can't make redirect work. I have:

Service: svc.sub.domain.com

auth-signin: https://oauth2-proxy.services.sub.domain.com/oauth2/start?rd=https://$host$request_uri
auth-url: https://oauth2-proxy.services.sub.domain.com/oauth2/auth

cookie_domain = ".domain.com"

I've also tried different combinations for whitelist_domain:
".domain.com"
".sub.domain.com"
"svc.sub.domain.com"

Even tried to provide a list as:
whitelist_domain = [ ".domain.com", ".sub.domain.com", "svc.sub.domain.com" ]

But nothing works and I'm still redirected to https://oauth2-proxy.services.sub.domain.com/

Can anyone suggest any ideas where I'm wrong?

[messiahUA]

Figured out that the problem is the wrong parameter name.
It is an inconsistency in:
https://github.com/pusher/oauth2_proxy/blob/10adb5c516b5a15756a7baa50aa2d8551a6655b8/options.go#L51

"whitelist_domains" in config and "whitelist-domain" as a flag. The documentation states only about cli options.

[nonylene]

The documentation states only about cli options.

This behavior is documented...

Environment variables
Every command line argument can be specified as an environment variable by prefixing it with OAUTH2_PROXY_, capitalising it, and replacing hypens (-) with underscores (_). If the argument can be specified multiple times, the environment variable should be plural (trailing S).

https://pusher.github.io/oauth2_proxy/configuration

PS. I've also set with the wrong variable name and reached this issue :)

[nonylene]

Oops, you were talking about config file, not environment variables.

[github-actions]

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.

[xUnholy]

This thread has been closed for a while but I'm experiencing a 404 on my redirect.

Here is my HelmRelease

---
apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: oauth2-proxy
  namespace: network
  annotations:
    fluxcd.io/ignore: 'false'
    fluxcd.io/automated: 'false'
spec:
  releaseName: oauth2-proxy
  helmVersion: v3
  chart:
    repository: https://kubernetes-charts.storage.googleapis.com/
    name: oauth2-proxy
    version: 3.1.0
  values:
    image:
      repository: 'quay.io/pusher/oauth2_proxy'
      tag: v5.1.1-arm64
    config:
      existingSecret: oauth2-proxy
    extraArgs:
      provider: github
      github-org: raspbernetes
      email-domain: '*'
      cookie-domain: .raspbernetes.com
      whitelist-domain:
        - raspbernetes.com
        - .raspbernetes.com
      cookie-samesite: none
    ingress:
      enabled: true
      path: /oauth2
      hosts:
        - auth.raspbernetes.com
      annotations:
        kubernetes.io/ingress.class: nginx
        cert-manager.io/cluster-issuer: 'letsencrypt-staging'
      tls:
        - secretName: auth.raspbernetes.com-tls
          hosts:
            - auth.raspbernetes.com

I have my ingress with the following annotations:

nginx.ingress.kubernetes.io/auth-url: 'https://auth.raspbernetes.com/oauth2/auth'
nginx.ingress.kubernetes.io/auth-signin: 'https://auth.raspbernetes.com/oauth2/start?rd=$escaped_request_uri'

I login to Github as expected, but the redirect just 404's

I've done the recommendations as mentioned above but to no avail, would love any thoughts on what I might be missing?

In my oauth2-proxy pod logs I can see the following:

[2020/07/21 08:13:14] [oauthproxy.go:871] Error loading cookied session: Cookie "_oauth2_proxy" not present

10.32.0.19 - - [2020/07/21 08:13:14] auth.raspbernetes.com GET - "/oauth2/auth" HTTP/1.1 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36" 401 21 0.004

10.32.0.19 - - [2020/07/21 08:13:15] auth.raspbernetes.com GET - "/oauth2/start?rd=%2F" HTTP/1.1 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36" 302 318 0.000

[messiahUA]

@xUnholy is there a reason you have "rd=$escaped_request_uri"? maybe it should be something else?

[xUnholy]

@messiahUA that was what they showed in the docs https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/

[wesleydebruijn]

@xUnholy I had the same issue while using $escaped_request_uri. Using the following auth-signin fixed it for me:

nginx.ingress.kubernetes.io/auth-signin: "https://example.com/oauth2/start?rd=https://$host$request_uri"

[pavanparthasarathy]

@JoelSpeed I'm facing one error. I have configured the domain abc.test.com and when I authenticate I get the error "AADSTS500111: The reply uri specified in the request has an invalid scheme."
My redirect url is also abc.test.com

[JoelSpeed]

Please ensure you set the --redirect-url option and put the correct scheme on the start of that URL. This looks like an issue from your Identity Provider because this URL has been inferred (wrongly) rather than set explicitly

[AurimasNav]

@messiahUA that was what they showed in the docs https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/

That is because in the documentation you are referring to is showcasing a scenario where same fqdn is used for both oauth and for service ingresses. It is different in your case.

Figured out that the problem is the wrong parameter name. It is an inconsistency in: https://github.com/pusher/oauth2_proxy/blob/10adb5c516b5a15756a7baa50aa2d8551a6655b8/options.go#L51

"whitelist_domains" in config and "whitelist-domain" as a flag. The documentation states only about cli options.

Almost exactly my issue as well, thanks.
#2000