ProxyAuth not working correctly with Caddy

[activeshadow]

Hello, and thank you for such a great looking project!

I'm trying to use VoidAuth's ProxyAuth capability in front of a simple hello world web app with Caddy, all running on containers. I can log into VoidAuth, and the x-voidauth-session cookie works properly (I don't have to log into VoidAuth each time I visit it). The Caddy configuration also looks to be working correctly, because when I browse to the hello world web app it will redirect me to VoidAuth and require me to login if I'm not logged in already.

From here though, I get into an endless redirect loop and I cannot figure out why. Has anyone else experienced this?

I am using Caddy's Local HTTPS certificate, and I have added it to my browser's cert store such that when I browse to VoidAuth or my hello world web app the browser considers the page secure. I also have a local DNS server that's serving up the testing.local domain.

Please help! 🙏🏻

Docker Compose:

services:
  caddy:
    image: caddy:latest
    ports:
      - "127.0.0.1:80:80"
      - "127.0.0.1:443:443"
      - "127.0.0.1:443:443/udp"
    volumes:
      - ./caddy/conf:/etc/caddy
      - ./caddy/site:/srv
      - ./caddy/data:/data
      - ./caddy/config:/config
  voidauth:
    image: voidauth/voidauth:latest
    volumes:
      - ./voidauth/config:/app/config
      - ./voidauth/db:/app/db
    environment:
      APP_URL: https://auth.testing.local
      STORAGE_KEY: <32 character key>
      DB_ADAPTER: sqlite
      ENABLE_DEBUG: true
  helloworld:
    image: crccheck/hello-world:latest

Caddyfile:

auth.testing.local {
  reverse_proxy voidauth:3000
}

hello.testing.local {
  forward_auth voidauth:3000 {
    uri /api/authz/forward-auth
    copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
  }

  reverse_proxy helloworld:8000
}

VoidAuth Debug Logs:

voidauth-1  | {"timestamp":1787845922003,"level":"debug","message":"API Response Sent","request":{"ip":"172.18.0.1","method":"GET","path":"/api/proxyauth_cb"},"user":{"id":"1c9111f1-67dd-4c19-8681-15277a820f32","username":"foobar","source":"session","amr":["pwd"]},"response":{"statusCode":302,"location":"https://hello.testing.local/"}}
voidauth-1  | {"timestamp":1787845922009,"level":"debug","message":"API Response Sent","request":{"ip":"172.18.0.1","method":"GET","path":"/api/authz/forward-auth"},"proxyauth":{"action":"redirect_to_login","reason":"session_not_found","url":"https://hello.testing.local/","matchedDomain":"hello.testing.local/*"},"response":{"statusCode":302,"location":"https://auth.testing.local/oidc/auth?client_id=proxyauth_internal_client&response_type=none&scope=openid&redirect_uri=https%3A%2F%2Fauth.testing.local%2Fapi%2Fproxyauth_cb%3Fproxyauth_url%3Dhttps%253A%252F%252Fhello.testing.local%252F"}}
voidauth-1  | {"timestamp":1787845922015,"level":"debug","message":"API Response Sent","request":{"ip":"172.18.0.1","method":"GET","path":"/oidc/auth"},"user":{"id":"1c9111f1-67dd-4c19-8681-15277a820f32","username":"foobar","source":"session","amr":["pwd"]},"response":{"statusCode":303,"location":"https://auth.testing.local/api/proxyauth_cb?proxyauth_url=https%3A%2F%2Fhello.testing.local%2F&iss=https%3A%2F%2Fauth.testing.local%2Foidc"}}

[yudin-s]

I think the loop is caused by cookie scope, not by the Caddy route to the hello-world container.

The important clue is this sequence:

1. /api/proxyauth_cb sees the VoidAuth session and redirects to https://hello.testing.local/.
2. The next /api/authz/forward-auth request says reason: "session_not_found".

That usually means the browser has a valid x-voidauth-session cookie for auth.testing.local, but it is not sending that cookie when it requests hello.testing.local. Caddy can only forward the cookies that arrived on the protected host request, so VoidAuth sees you as logged in on the auth host but anonymous on the protected host.

In the current source, SESSION_DOMAIN controls the shared session cookie domain, and proxyAuth() also checks that the protected hostname is reachable from that session domain. With your local names, I would set it explicitly:

voidauth:
  environment:
    APP_URL: https://auth.testing.local
    SESSION_DOMAIN: testing.local
    STORAGE_KEY: <32 character key>
    DB_ADAPTER: sqlite
    ENABLE_DEBUG: true

Then recreate/restart the VoidAuth container and log in again so the cookie is reissued with the shared domain. Also make sure the ProxyAuth domain in VoidAuth is something that matches the protected app, for example hello.testing.local/*.

Your Caddy forward_auth shape is close to what the VoidAuth route expects: it builds the checked URL from X-Forwarded-Proto, X-Forwarded-Host, and X-Forwarded-Uri. Since your log already shows url: "https://hello.testing.local/" and matchedDomain: "hello.testing.local/*", those headers and the domain match are probably fine. The missing part is the session cookie being available on hello.testing.local.

After restart, check the browser devtools cookie entry. If it is still scoped only to auth.testing.local, the loop will continue. If it is scoped to testing.local, the next /api/authz/forward-auth call should become access_granted.

If this fixes the redirect loop, please mark the answer so the next Caddy/ProxyAuth setup can spot the session-domain requirement.