[Feature]: Should send X-Forwarded-Host header to upstream host

[NiroDeveloper]

Motivation

The proxy passes the Host header by default, but in certain environments this does not work. This behavior makes routing difficult. You can disable this behavior with --pass-host-header, but the initial host name will be lost.

The oauth2 proxy should behave like every other reverse proxy and set the "X-Forwarded-Host" header in the upstream. I can't understand why it seems that no one else has this problem.

Possible solution

We could also just enable this if a new flag is set, which would not change the current behavior and there would be no problems with updates.

Provider

None

[JoelSpeed]

You can disable this behavior with --pass-host-header, but the initial host name will be lost.

Can you expand on this?

I can't understand why it seems that no one else has this problem.

Yes that's curious, can you expand a little bit more on the use case as from what you've described you're right, I would expect this to have come up more, but it hasn't, it's curious 🤔

[NiroDeveloper]

Explicitly i am talking about a integration into a Kubernetes cloud platform. The best possible architecture I can imagine would be to put the OAUth2 proxy in its own pod with its own service.

Routing in this system does work over service names, so not over ip addresses. Also a correct Host header is required so the request is routed correctly to the given service. So if --pass-host-header is enabled (default), the connection between the oauth2 proxy and application is not working.

Solution for this is currently to disable --pass-host-header, so the http upstream communication is working. But by disabling this flag, the http upstream request does not contain the real Domain from the Client/Browser ... it got just overwritten by the service name. Some application frameworks now have problems with redirects because they do not know the real domain requested by the client.

The solution in my eyes would be to add an X-Forwarded-Host header, so that the real host name is not lost. I searched for this problem a long time, because it was the most obvious solution for me. You can also put the oauth2 proxy into the application pod, but i think this is not a clean solution.

[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.

[tuunit]

The best architecture for this situation is using oauth2-proxy just for internal auth requests.

Istio and nginx support this.

Ingress
|
v
Controller ---> Verify with ouath2-proxy 
|
| If login successful allow normal routing
v
Your service or virtual service
|
v
Your pods

[tuunit]

Istio Example: https://elastisys.com/istio-and-oauth2-proxy-in-kubernetes-for-microservice-authentication/

Nginx example: https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/

[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.