Proxy forward auth always granting access -> 200

EkiciLP commented

2026-05-28 19:14:42 -05:00

(Migrated from github.com)

Describe the bug:

The forward auth endpoint always returns 200 even when hit using insomnia, a logged out incognito tab or using curl. In my traefik forward auth setup it also always grants access no matter what I do.
I've also tried to add a wildcard / domain with a group no user has been assigned to explicitly deny access but still 200.

To Reproduce:

hit the endpoint

Expected behavior:

Return 403 when not identified or no rule exists.

Database Driver:

Postgres

### Describe the bug: The forward auth endpoint always returns 200 even when hit using insomnia, a logged out incognito tab or using curl. In my traefik forward auth setup it also always grants access no matter what I do. I've also tried to add a wildcard */* domain with a group no user has been assigned to explicitly deny access but still 200. ### To Reproduce: 1. hit the endpoint ### Expected behavior: Return 403 when not identified or no rule exists. ### Database Driver: Postgres

notquitenothing commented

2026-05-28 19:53:09 -05:00

(Migrated from github.com)

Please set the container environment variable ENABLE_DEBUG=true, and attempt to verify that the VoidAuth forward-auth endpoint is being hit and returning a statusCode 200. You would see VoidAuth container logs that look like:

{"timestamp":1780015588542,"level":"debug","message":"API Response Sent","details":{"request":{"ip":"1.2.3.4","method":"GET","path":"/api/authz/forward-auth"},"user":{"id":"abc123-7020-411b-81a2-02bd07bc0b15","username":"some_username","source":"session","amr":["pwd"]},"proxyauth":{"action":"access_granted","domain":"your-domain.example.com/*"},"response":{"statusCode":200}}}

From a preliminary test using the latest version and Caddy, it appears that I correctly get a status 302 that redirects to the login page.

Please set the container environment variable `ENABLE_DEBUG=true`, and attempt to verify that the VoidAuth forward-auth endpoint is being hit and returning a statusCode `200`. You would see VoidAuth container logs that look like: ``` {"timestamp":1780015588542,"level":"debug","message":"API Response Sent","details":{"request":{"ip":"1.2.3.4","method":"GET","path":"/api/authz/forward-auth"},"user":{"id":"abc123-7020-411b-81a2-02bd07bc0b15","username":"some_username","source":"session","amr":["pwd"]},"proxyauth":{"action":"access_granted","domain":"your-domain.example.com/*"},"response":{"statusCode":200}}} ``` From a preliminary test using the latest version and Caddy, it appears that I correctly get a status `302` that redirects to the login page.

EkiciLP commented

2026-05-29 02:54:41 -05:00

(Migrated from github.com)

Yes I have tried that and it always returns 200 with the message "access_granted"

{"timestamp":1780036266227,"level":"debug","message":"API Response Sent","details":{"request":{"ip":"10.0.3.1","method":"GET","path":"/api/authz/forward-auth"},"proxyauth":{"action":"access_granted"},"response":{"statusCode":200}}}

Yes I have tried that and it always returns 200 with the message "access_granted" ``{"timestamp":1780036266227,"level":"debug","message":"API Response Sent","details":{"request":{"ip":"10.0.3.1","method":"GET","path":"/api/authz/forward-auth"},"proxyauth":{"action":"access_granted"},"response":{"statusCode":200}}}``

notquitenothing commented

2026-05-29 17:51:26 -05:00

(Migrated from github.com)

~~If you would be interested in (temporarily) using the :edge tag it should show additional details of the forward-auth when access is granted in the debug logs.~~ My initial suspicion is that the host header(s) being passed to VoidAuth is of itself (auto-granted) instead of the protected resource, which could be confirmed with the additional logs. Those logs are now available in the latest release, so if you update to the most recent version should see a bit more information when access is granted.

~~If you would be interested in (temporarily) using the `:edge` tag it should show additional details of the forward-auth when access is granted in the debug logs.~~ My initial suspicion is that the host header(s) being passed to VoidAuth is of itself (auto-granted) instead of the protected resource, which could be confirmed with the additional logs. Those logs are now available in the latest release, so if you update to the most recent version should see a bit more information when access is granted.

EkiciLP commented

2026-06-01 10:59:40 -05:00

(Migrated from github.com)

The following log is from a request using insomnia with no headers added:

{"timestamp":1780329237380,"level":"debug","message":"API Response Sent","details":{"request":{"ip":"REDACTED","method":"GET","path":"/api/authz/forward-auth"},"proxyauth":{"action":"access_granted","reason":"request_to_self_url"},"response":{"statusCode":200}}}

And the same when coming from traefik:

{"timestamp":1780329471202,"level":"debug","message":"API Response Sent","details":{"request":{"ip":"10.0.3.1","method":"GET","path":"/api/authz/forward-auth"},"proxyauth":{"action":"access_granted","reason":"request_to_self_url"},"response":{"statusCode":200}}}

The following log is from a request using insomnia with no headers added: ```json {"timestamp":1780329237380,"level":"debug","message":"API Response Sent","details":{"request":{"ip":"REDACTED","method":"GET","path":"/api/authz/forward-auth"},"proxyauth":{"action":"access_granted","reason":"request_to_self_url"},"response":{"statusCode":200}}} ``` And the same when coming from traefik: ```json {"timestamp":1780329471202,"level":"debug","message":"API Response Sent","details":{"request":{"ip":"10.0.3.1","method":"GET","path":"/api/authz/forward-auth"},"proxyauth":{"action":"access_granted","reason":"request_to_self_url"},"response":{"statusCode":200}}} ```

notquitenothing commented

2026-06-03 21:49:51 -05:00

(Migrated from github.com)

The logs shown indicate access granted because "reason":"request_to_self_url"; that means that the X-Forwarded-* Headers being sent from your reverse-proxy to VoidAuth indicate the URL that VoidAuth itself is hosted on, instead of the protected/original URL. That could be due to a misconfiguration of the reverse-proxy forwardAuth, make sure that the Traefik config matches what is shown in the ProxyAuth docs.

The logs shown indicate access granted because "reason":"request_to_self_url"; that means that the X-Forwarded-* Headers being sent from your reverse-proxy to VoidAuth indicate the URL that VoidAuth itself is hosted on, instead of the protected/original URL. That could be due to a misconfiguration of the reverse-proxy forwardAuth, make sure that the Traefik config matches what is shown in the [ProxyAuth docs](https://voidauth.app/#/ProxyAuth-and-Trusted-Header-SSO-Setup?id=traefik).

EkiciLP commented

2026-06-04 07:31:51 -05:00

(Migrated from github.com)

It should be configured exactly as described:

voidauth traefik config:

      - traefik.enable=true
      - traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https
      - traefik.http.routers.http-0-uc4o0w8w4044gk8csksogc4w-voidauth.entryPoints=http
      - traefik.http.routers.http-0-uc4o0w8w4044gk8csksogc4w-voidauth.middlewares=redirect-to-https
      - 'traefik.http.routers.http-0-uc4o0w8w4044gk8csksogc4w-voidauth.rule=Host(`auth.MYDOMAIN.net`) && PathPrefix(`/`)'
      - traefik.http.routers.http-0-uc4o0w8w4044gk8csksogc4w-voidauth.service=http-0-uc4o0w8w4044gk8csksogc4w-voidauth
      - traefik.http.routers.https-0-uc4o0w8w4044gk8csksogc4w-voidauth.entryPoints=https
      - 'traefik.http.routers.https-0-uc4o0w8w4044gk8csksogc4w-voidauth.rule=Host(`auth.MYDOMAIN.net`) && PathPrefix(`/`)'
      - traefik.http.routers.https-0-uc4o0w8w4044gk8csksogc4w-voidauth.service=https-0-uc4o0w8w4044gk8csksogc4w-voidauth
      - traefik.http.routers.https-0-uc4o0w8w4044gk8csksogc4w-voidauth.tls.certresolver=letsencrypt
      - traefik.http.routers.https-0-uc4o0w8w4044gk8csksogc4w-voidauth.tls=true
      - traefik.http.services.http-0-uc4o0w8w4044gk8csksogc4w-voidauth.loadbalancer.server.port=3000
      - traefik.http.services.https-0-uc4o0w8w4044gk8csksogc4w-voidauth.loadbalancer.server.port=3000

application traefik config:

      - traefik.http.routers.https-0-rg90kitb7myrgxogzbp29kiz-svg-templater.middlewares=voidauth
      - 'traefik.http.middlewares.voidauth.forwardAuth.address=https://auth.MYDOMAIN.net/api/authz/forward-auth'
      - traefik.http.middlewares.voidauth.forwardAuth.trustForwardHeader=true
      - 'traefik.http.middlewares.voidauth.forwardAuth.authResponseHeaders=Remote-User,Remote-Name,Remote-Email,Remote-Groups'

the rest of the application labels is using the same structure as voidauth since im using coolify for deployment.

It should be configured exactly as described: voidauth traefik config: ```yaml - traefik.enable=true - traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https - traefik.http.routers.http-0-uc4o0w8w4044gk8csksogc4w-voidauth.entryPoints=http - traefik.http.routers.http-0-uc4o0w8w4044gk8csksogc4w-voidauth.middlewares=redirect-to-https - 'traefik.http.routers.http-0-uc4o0w8w4044gk8csksogc4w-voidauth.rule=Host(`auth.MYDOMAIN.net`) && PathPrefix(`/`)' - traefik.http.routers.http-0-uc4o0w8w4044gk8csksogc4w-voidauth.service=http-0-uc4o0w8w4044gk8csksogc4w-voidauth - traefik.http.routers.https-0-uc4o0w8w4044gk8csksogc4w-voidauth.entryPoints=https - 'traefik.http.routers.https-0-uc4o0w8w4044gk8csksogc4w-voidauth.rule=Host(`auth.MYDOMAIN.net`) && PathPrefix(`/`)' - traefik.http.routers.https-0-uc4o0w8w4044gk8csksogc4w-voidauth.service=https-0-uc4o0w8w4044gk8csksogc4w-voidauth - traefik.http.routers.https-0-uc4o0w8w4044gk8csksogc4w-voidauth.tls.certresolver=letsencrypt - traefik.http.routers.https-0-uc4o0w8w4044gk8csksogc4w-voidauth.tls=true - traefik.http.services.http-0-uc4o0w8w4044gk8csksogc4w-voidauth.loadbalancer.server.port=3000 - traefik.http.services.https-0-uc4o0w8w4044gk8csksogc4w-voidauth.loadbalancer.server.port=3000 ``` application traefik config: ```yaml - traefik.http.routers.https-0-rg90kitb7myrgxogzbp29kiz-svg-templater.middlewares=voidauth - 'traefik.http.middlewares.voidauth.forwardAuth.address=https://auth.MYDOMAIN.net/api/authz/forward-auth' - traefik.http.middlewares.voidauth.forwardAuth.trustForwardHeader=true - 'traefik.http.middlewares.voidauth.forwardAuth.authResponseHeaders=Remote-User,Remote-Name,Remote-Email,Remote-Groups' ``` the rest of the application labels is using the same structure as voidauth since im using coolify for deployment.

notquitenothing commented

2026-06-04 23:16:49 -05:00

(Migrated from github.com)

I am not familiar with coolify and might be reading your configs wrong but I think some of those labels should be on the main Traefik service (or perhaps in the Traefik service startup command) instead of the VoidAuth service, and some labels on the protected application should be on VoidAuth. I will update the ProxyAuth Traefik documentation to hopefully be more clear

Rows
Columns

Proxy forward auth always granting access -> 200 #450

Describe the bug:

To Reproduce:

Expected behavior:

Database Driver: