authentik forward auth with Traefik

Traefik's forwardAuth middleware does not pass identity to the application on its own. After the outpost answers an authentication check, Traefik copies only the response headers you list in the middleware's authResponseHeaders setting onto the request it forwards upstream. Anything not listed is dropped, so the first decision is to keep that list as short as the application needs. Typically this means the user identifier and the groups or email claims the application actually reads. Confirm the exact header names against the outpost version you run before writing them into the application configuration, because the names authentik sets for forward auth have changed across releases and an application that reads the wrong header will fail in ways that look like login problems.

The application should trust only the headers that Traefik sets after a successful check. Most applications accept any header a client sends, so a visitor who reaches the application directly could type in an identity header and be signed in as someone else. Treat the proxy as the only path in: restrict the application's network so its port is reachable only from the Traefik container or host, and remove any published port that bypasses the router. Also make sure Traefik strips client-supplied copies of the identity headers before forwardAuth runs. Test this by sending a request straight to the application with a forged header and confirming it is rejected or ignored.

Plan a verification step for each header and each route. For a sample request through a protected hostname, check that the application sees the expected user and groups, that a user outside the authorized group receives the authentik login or access denied response, and that a forged header from outside the proxy has no effect. Record the authentik version, the Traefik version and the middleware definition with the test results, so a later upgrade of either component can be re-checked against the same expectations. If your application reads headers that authentik does not supply by default, ask the authentik documentation or your own configuration review how to add a custom header before relying on it in production.

After go-live, the first thing to watch is whether the Traefik forwardAuth middleware still gets a fast, correct answer from the authentik outpost. Monitor the path end to end: request latency and error rates on the outpost endpoint that the middleware calls, Traefik access logs showing 401 and 403 responses on protected routes, and authentication failures on the authentik side. A sudden rise in 500 responses from the middleware usually means the outpost cannot reach the authentik server or its configuration has drifted, while a rise in redirects on API clients often points to a missing bypass or a header mismatch. Confirm which metrics and log streams your authentik version exposes before you build dashboards, because the exact names and endpoints should come from the documentation for your release rather than from memory.

Upgrades need a deliberate rule for the outpost and the server. The outpost that Traefik talks to should run the same authentik version as the server, so schedule the server and outpost upgrades together and test the middleware on a staging stack first. Read the upgrade notes for each release in the sequence you need to follow, since authentik's upgrade guidance expects you to move through versions in order. Pin image tags in your Compose files or Helm values instead of using floating tags, and record which outpost image each Traefik-protected application uses so a rollback can restore a matching pair. Security releases are announced at least 24 hours in advance, and the security policy lists the supported version lines, so check that your running line still appears there at each review.

The 2025.10 release notes state that authentik no longer uses Redis, moving caching, tasks, sessions and WebSocket functions to PostgreSQL, and they warn of roughly 50% more PostgreSQL connections after upgrading. For a forward auth deployment this matters because every protected request depends on the session and outpost path. Before upgrading across that release, raise the PostgreSQL connection limit or add pooling, watch active connection counts and errors during the first hours, and remove any Redis dependencies from your own runbooks and monitoring. Lockout recovery should be tested before it is needed: in a staging environment, lock out a test user, confirm which administrator account or recovery flow restores access, and confirm that an emergency bypass route for the admin interface does not depend on the forward auth middleware it protects.