Traefik forward-auth SSO holds up when the auth middleware sits on the public Host routers that need a login, while the IdP callback and auth service itself stay on a router that is not wrapped by that same middleware — otherwise you get a redirect loop the dashboard still reports as a matched route. Share one cookie domain across sibling apps on the same parent zone, keep ForwardAuth addressing the auth container by Compose DNS on the private network, and pass through X-Forwarded-Proto plus the original Host so the IdP redirect URI stays on the public name users actually typed. TLS should terminate on the websecure entrypoint before the auth hop; mixing cleartext internal callbacks with HTTPS public names is a common source of “works in curl, fails in the browser” sessions.

After applying labels I confirm which router and middleware chain each hostname hit, that an unauthenticated request gets a single redirect to the IdP rather than an app 401 page, and that a second tab on another Host under the same cookie domain reuses the session without a second prompt. Also probe the auth service health from Traefik’s network and the protected app separately — a 502 on the app with a healthy IdP is usually the ForwardAuth address or trust headers drifting after a compose rename, not the identity provider itself.