[BUG] Forward Auth Redirection error in v3.2.3
Need the help of @james-d-elliott with this
I setup a forward auth provider for Zoraxy via Authentik, but I only get redirection errors. In authentik I did the following steps:
In Zoraxy I set the following:
Authentik is running on sso.domain.com. I used this PR for configurating: https://github.com/tobychui/zoraxy/pull/568
Host Environment (please complete following information, DO NOT REMOVE ANY FIELD(S)):
- Arch: x64, arm64
- Device: datacenter and ATX Tower
- OS: Ubuntu Server 24.04, Fedora 42
- Are you using Docker? NO
Try using the URL documented for traefik: https://docs.goauthentik.io/docs/add-secure-apps/providers/proxy/server_traefik
I tried in Zoraxy now the URLs:
https://sso.domain.com/outpost.goauthentik.io
and
https://sso.domain.com/outpost.goauthentik.io/auth/traefik
Both end up in 400 Bad request
Is https://sso.domain.com a URL hosted behind Zoraxy?
Yes it points to the docker container of Authentik.
Zoraxy is running on the host system, not in docker!
Does Zoraxy offer a means to turn off X-Forwarded-* headers for a particular path?
You can remove headers under "HTTP Proxy Rules" -> "Headers", but for all paths...
@tobychui is it possible to turn off headers only for a specific path?
One other thing to try then is setting the same URL as Zoraxy uses to reverse proxy for sso.domain.com, and add /outpost.goauthentik.io/auth/traefik to the end. I was unable to find someone using Authentik who would test it so this may just need some tweaks.
What I believe is occurring is Zoraxy is changing the required X-Forward-* headers.
I already tried this:
Zoraxy proxys the domain sso.domain.com to the Authentik container
I tried this URL in Zoraxy:
https://sso.domain.com/outpost.goauthentik.io/auth/traefik
As mentioned above, it ends in error 400 bad request
I understand that part, what I mean is for it to proxy to sso.domain.com there must be a URL used to tell Zoraxy how to proxy sso.domain.com to the container, that URL, not https;//sso.domain.com.
@tobychui is it possible to turn off headers only for a specific path?
Good question. You mean in code or from the UI? I think it is possible to expose a header editing interface for the forward-auth module, but in the UI I guess there is no such feature at the moment.
If you need such feature in the UI, feel free to open a new enhancement request :)
@tobychui have you tried in Zoraxy the local container URL? I've used this for Authelia in Zoraxy UI: http://xxx.xxx.xxx.x:9091/api/authz/forward-auth
any news?
Hmm, well to be honest I have no idea how to fix it. Anyone have ideas on what is the issue here? Or you guys just need a exclusion function in custom header to make it work?
I can understand the desire to hit the abort here with what appears at first glance to be lots of issues but I think this is the best path long term with the best security outcome for users as well as the highest interoperability.
From what I can tell @mbo99 got it working, if you use the private URL not the Zoraxy hosted URL it works, and tested this with an Authelia user in the Authelia discord before it was merged. The issue is Zoraxy is overriding the X-Forwarded-* headers. The most problematic of these is the X-Forwarded-For header for security reasons.
I see four effective secure solutions:
- Use the private URL as described, we should realistically update the documentation provided if this is the chosen solution. This is probably the best as you can ensure privacy is 100% maintained for the forward auth request. This also has been validated to work with Authelia, I'd love for someone to help me test this with Authentik (my contact details are in my bio).
- Add an option to disable overriding these headers for the sake of forward auth on specific URI's. This could be problematic for the X-Forwarded-For header if not done correctly.
- Add another option that changes the behavior so it acts the same as the k8s nginx ingress auth request method (X-Original-URL and X-Original-Method).
- Add a specialized signed header which allows saving and restoring these headers between requests.