[Bug]: An invalid redirect to a non-whitelisted domain creates a valid session cookie after redirecting to "/"

[matzegebbe]

OAuth2-Proxy Version

7.6.0

Provider

azure

Expected Behaviour

When the whitelist-domain configuration does not match the redirect URL, the user is still redirected to the oauth2-proxy root URL ("/") instead of being halted with an HTTP 403 error

--whitelist-domain=localhost

For us, this has led to a redirection to a page that does not exist when accessed from the outside on the first attempt (which triggers a 403 or 404 error by default backend config) but has a valid OAuth2 proxy cookie afterwards. On the user's second attempt (because no external authentication redirect occurs), they are authenticated and can access the website, even though it is not on the whitelist domain.

Current Behaviour

calling http://localhost:4180/oauth2/start?rd=https://example.com/foo

[2024/05/08 18:06:59] [validator.go:60] Rejecting invalid redirect "https://example.com/foo": domain / port not in whitelist
[2024/05/08 18:06:59] [director.go:85] Invalid redirect provided in rd querystring parameter: https://example.com/foo
[2024/05/08 18:06:59] [validator.go:63] Rejecting invalid redirect "/oauth2/start?rd=https://example.com/foo": not an absolute or relative URL
[2024/05/08 18:06:59] [director.go:85] Invalid redirect generated from X-Forwarded-Uri header: /oauth2/start?rd=https://example.com/foo
...
192.168.65.1:37860 - ed5f1146-eab9-462f-b903-7559cfe9fa09 - - [2024/05/08 18:06:59] localhost:4180 GET - "/oauth2/start?rd=https://example.com/foo" HTTP/1.1 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:125.0) Gecko/20100101 Firefox/125.0" 302 369 0.000
...
[2024/05/08 18:06:59] [AuthSuccess] Authenticated via OAuth2: Session{email:

Steps To Reproduce

1. start oauth2 proxy without upstream and whitelist domain
2. call oauth2-proxy with a domain not in the whitelist http://localhost:4180/oauth2/start?rd=https://example.com/foo

Possible Solutions

Instead of sending a 302 on invalid redirect, send a 403

Configuration details or additional information

We are using Ingress-Nginx External OAUTH Authentication. If it's an expected behavior for some reason feel free to close this issue with a comment