Error redeeming authorization code

[weeco]

I just setup the SSO auth, but I get an internal server error after I chose my google account:

The SSO proxy log says:

{"error":"got 403 from \"https://sso-auth.service.int.mydomain.com/redeem\" \u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e403 Forbidden\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody bgcolor=\"white\"\u003e\r\n\u003ccenter\u003e\u003ch1\u003e403 Forbidden\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003enginx/1.15.3\u003c/center\u003e\r\n\u003c/body\u003e\r\n\u003c/html\u003e\r\n","level":"error","msg":"error redeeming authorization code","remote_address":"x.x.x.x","service":"sso-proxy","time":"2018-10-26 14:51:39.10262"}
{"http_status":500,"level":"info","msg":"error page","page_message":"Internal Error","page_title":"Internal Error","service":"sso-proxy","time":"2018-10-26 14:51:39.10262"}

What is this error message supposed to tell me and how can I fix it?

error redeeming authorization code

In the SSO auth container I only see a few 302 redirects, but no error messages or warnings.

[danbf]

in that log the sso-proxy is trying to redeem from the sso-auth at this address sso-auth.service.int.mydomain.com. in this case unsuccessfully. most probably because the of a host name mismatch on for the sso-auth.

the host names of the sso-proxy PROVIDER_URL, sso-auth HOST and REDIRECT_URL must all match and resolve for the browser client and the sso-proxy service. sso-proxy PROXY_PROVIDER_URL optionally can be used in a split dns environment and it's host address should resolve to the sso-auth servers ip address

[weeco]

@danbf Thank you for your answer. I checked your mentioned environment variables and I saw they were all equal, except the "HOST" environment variable, which was missing the https:// prefix. Therefore I added the protocol to the HOST environment variable, but the error is still the same.

What else could be wrong? The log message itself is unfortunately not really helpful.

[danbf]

@weeco sorry i was not clearer. HOST here

sso/quickstart/kubernetes/sso-auth-deployment.yml

Lines 31 to 32 in 6db5495

	- name: HOST
	value: sso-auth.mydomain.com

is just a hostname, no protocol.

trying to think up the rest of the reasons why a 403 would be returned. can you tell me a bit more about your k8 setup, is it AWS like the blog https://medium.com/@while1eq1/single-sign-on-for-internal-apps-in-kubernetes-using-google-oauth-sso-2386a34bc433 . and it's probably better to use your real domains substituting for the mydomain.com in the example code.

[weeco]

Hmm accordingly my HOST env variable was already correct. Unfortunately I am not allowed to expose the actual domain names but I carefully replaced the domain name with the example values.

I am running it inside of a Gcloud Kubernetes Cluster. I wrote my own Helm chart which is indeed based on the kubernetes config given in the medium article. The SSO auth and proxy are sitting in it's own namespace (ingress), while the protected backend service sits in another namespace (monitoring). Since we don't have log messages which tell us what is wrong, what could I do so that we can investigate the problem? Should I copy all the kubernetes configs where I'll redact stuff like the actual domains?

Edit: Specifically I am surprised that the error message thrown in the SSO proxy error redeeming authorization code which is apparently caused inside of the SSO auth container, does not log any details in the sso auth application. However I see a couple 302 redirects in the SSO auth container. Maybe that's related?

[danbf]

when i saw something like this, it was a 404 and it was the sso-auth not getting an expected host header, #88 (comment) which is fixed in

sso/internal/proxy/providers/sso.go

Line 113 in af20521

req.Host = p.RedeemURL.Host

.

since sso-auth doesn't seem to produce a 403, https://github.com/buzzfeed/sso/search?q=403&unscoped_q=403 , i'm thinking it's the nginx-ingress-controller setup that's the problem. to the extent possible it would be great to see your configs. maybe we could work together better on this if we cut a PR for a quick start for the environment you are trying to work in a Gcloud Kubernetes Cluster quickstart.

[danbf]

and i see there is an issue already for this; #44

[weeco]

Ok I'll tomorrow post the kubernetes config. #44 is about creating a general helm chart, however I have created a kubernetes chart for our specific needs. But I reviewed the official helm chart and gave me input there as well.

[weeco]

Ok I figured it out. You were right, it was the ingress controller. We have configured the ingress controller to set a default whitelist source IP range if no whitelist is specified. So that was totally my fault.

One could add some advanced topics in the medium article which describes how to create two seperate ingresses (one for the proxy and one for the oauth container) so that you can specify a whitelist for those who are allowed to authenticate and another ingress with a global whitelist, so that the Google OAuth callback reaches your container.

Thanks for all the suppport!

[danbf]

i added in a split dns support for sorta what you are talking about in #88 , PROXY_PROVIDER_URL and it provides the ability to route the sso-proxy->sso-auth traffic via a different path then the client->sso-auth traffic. it might be useful to you in your setup.

we have an internal to-do to setup a kubernetes quickstart where we could include stuff like this. the issues you brought up i think will help with that.

[rlabrecque]

Just wanted to comment on this as well after working through it.

Our issue ended up being similar. We currently have security groups to prevent access to our nodes.

So our proxy was hitting the following. Using PROXY_PROVIDER_URL fixed it, alternatively we can make these services public in our security group now.

{"error":"Post https://sso-auth.redacted.com/oauth2/redeem: net/http: request canceled (Client.Timeout exceeded while awaiting headers)","level":"error","msg":"error redeeming authorization code","remote_address":"10.42.3.2","service":"sso-proxy","time":"2020-11-24 19:41:51.883"}
{"http_status":500,"level":"info","msg":"error page","page_message":"Internal Error","page_title":"Internal Error","remote_address":"10.42.3.2","service":"sso-proxy","time":"2020-11-24 19:41:51.883"}

{"action":"callback","http_status":500,"level":"info","msg":"","remote_address":"10.42.3.2","request_duration":5001.3712940000005,"request_method":"GET","request_uri":"bleh.sso.redacted.tld/oauth2/callback?code=redacted","service":"sso-proxy","time":"2020-11-24 19:41:51.883","user":"","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.11 Safari/537.36"}

[rlabrecque]

Oh also PROXY_PROVIDER_URL got renamed to PROVIDER_URL_INTERNAL at some point.