Why authentik forward auth breaks behind a reverse proxy
Forward auth breaks behind a reverse proxy because three things must line up: the routes that send requests to the outpost, the cookies that carry the session across hostnames, and the proxy's trust in the client identity it forwards. When a protected application returns a redirect loop, a 404 on /outpost.goauthentik.io, or no identity headers after login, the symptom usually sits in one of these three areas, even though the error appears in the browser or the application. Troubleshooting starts by identifying which of them failed, not by changing settings until the error disappears.
The fix depends on the mode you chose. In single-application forward auth, only /outpost.goauthentik.io on the application's own domain is routed to the outpost, so a proxy rule that forwards only the application path will produce a 404 on the callback. In domain-level mode, the proxy relies on an authentication URL and a shared cookie domain across several applications, so a mismatch in cookie scope or authentication URL shows up as a loop that moves between hosts. Teams should confirm which mode their proxy configuration was written for before they edit anything, because the two modes have different required routes. The authentik forward auth documentation sets out each pattern.
Missing headers usually come from the proxy rather than from authentik. Identity headers are only passed through when the proxy copies them from the outpost response and when authentik trusts the proxy's forwarded addresses, so a reverse proxy that strips headers or sits outside the trusted range will drop the identity even after a successful login. Before opening a ticket, collect the proxy's route table, the cookie domain setting, and the outpost logs for one failing request. Those three artifacts let you tell whether a request never reached the outpost, reached it without a valid session, or reached it and lost its headers on the way back.
Which symptom points to which cause
Forward auth problems usually show up as one of a few symptoms at the browser or proxy, but the same symptom can come from different layers. Use the list below to pick the first area to check, then confirm it against the outpost logs and the proxy configuration before changing anything.
Redirect loops
A user bounces between the application and the login page and never reaches either. The usual suspects are a mismatch between the external hostname the browser uses and the one authentik sees, or a cookie that is set but not returned on the next request. Check the external host and the cookie domain together, and confirm that the authentication flow redirects to the same host the proxy serves. Start with the cookie domain.
404 on the outpost path
Requests to the outpost path return 404 from the proxy or the application instead of reaching authentik. This points to routing: only the /outpost.goauthentik.io path on the application domain should be sent to the outpost in single-application mode. Compare the proxy route table against the path in the provider settings, and check that the outpost container is reachable from the proxy at the address you configured.
Missing identity headers
The application loads after login but receives no user or group headers, so it treats the visitor as anonymous. Check that the proxy passes the headers authentik sets on to the upstream application, and that the application trusts the proxy as the source of those headers. A proxy that strips or rewrites headers before forward auth runs is a common cause.
Login succeeds but the session does not stick
authentik shows a successful sign-in, yet the next request asks for login again. This usually means the session cookie is scoped to a domain the browser does not send back to the application, or that the proxy is handling the cookie over plain HTTP where it expects HTTPS. Confirm the cookie name, domain and secure flag in the browser, and compare them with the application domain.
Wrong redirect host
After sign-in the browser lands on an internal hostname, a container address or an unexpected domain. The authentik external host setting or the forwarded host and scheme headers passed by the proxy are the first places to check. Trusted proxy configuration determines whether authentik believes those forwarded values, so verify that the proxy address is on the trusted list before editing the external host.
Single-application versus domain-level forward auth
This table compares the two forward auth modes authentik supports behind a reverse proxy, covering what must be routed, where the session cookie lives and where each mode tends to break. Read it before choosing a mode, and use the failure modes column as a checklist when a redirect loop or missing header appears.
| Aspect | Single-application mode | Domain-level mode |
|---|---|---|
| What must be routed | Only the /outpost.goauthentik.io path on the application domain is sent to the outpost | The authentication URL and the outpost path must both be reachable for every protected domain under the shared parent |
| Where the cookie is set | On the single application's host, so it is scoped to that one domain | On a shared parent cookie domain, so one login covers all protected hosts beneath it |
| Proxy configuration effort | Small: one path rule per application, repeated for each app | Larger: consistent auth URL, cookie domain and routing across every protected host |
| Typical failure: redirect loop | Outpost path not routed, so the login redirect never returns to the application | Cookie domain does not match the shared parent, so the session is not seen on the next host |
| Typical failure: 404 on outpost path | Path rule missing or applied to the wrong host block in the proxy | Auth URL points at a host that does not route the outpost path |
| Typical failure: missing headers | Proxy does not pass user headers from the outpost response to the upstream | Same header pass-through gap, plus trusted proxy settings that differ between hosts |
| When it fits | A few applications on separate hostnames, or teams that want isolated sessions | Many internal applications under one domain that should share a single sign-on session |
| What to check first | Route table for the application host and outpost logs for the callback request | Cookie domain value, auth URL reachability from each protected host and trusted proxy list |
How to diagnose forward auth step by step
This sequence isolates a forward auth failure by checking each hop in order: the route to the outpost path, the proxy's forwarded requests and headers, the cookie scope, the trusted proxy configuration, and finally the outpost logs. Each step ends with a check that tells you whether to move on or fix that layer.
Confirm the outpost path reaches authentik
Start at the reverse proxy configuration for the application domain. Confirm that requests to /outpost.goauthentik.io on that domain are routed to the authentik server, not to the protected application. In single-application mode this path must exist on the application domain itself. Request the path directly with curl from a host outside the proxy's internal network and inspect the response. A healthy route returns an authentik response, typically a redirect or an outpost reply, rather than a 404 from the application or the proxy. If you get a 404, the route is missing or points at the wrong upstream. Confirm the exact path and upstream in your own proxy configuration, since your proxy product and deployment layout determine the syntax.
Verify forwarded authentication requests and headers
Next, confirm that the proxy sends the authentication subrequest to the outpost path for every protected request, and that it passes the headers authentik needs to build the redirect and identify the user, including the original request URL and host. Compare the forwarded host, protocol and URI against what authentik expects for your external URL. Missing or rewritten headers commonly cause redirect loops or login pages that return to the wrong address. Use your proxy's debug or access logs to view one protected request and its subrequest. The check passes when the subrequest reaches authentik with the original host and path intact. Confirm the header names and proxy directives against the authentik forward auth documentation for your proxy.
Check the cookie domain in domain-level mode
If you run domain-level forward auth, the session cookie must be valid for every application under the shared domain. Inspect the cookie set after login in the browser developer tools and compare its Domain attribute with the cookie domain configured in the authentik provider. A mismatch means the browser never sends the session back to the protected application, which produces repeated login prompts or loops. Also confirm that the authentication URL points to the authentik external host under the same shared domain. Skip this step for single-application mode, where the cookie scope is the application host itself. The check passes when the cookie is present, scoped to the shared domain, and sent on the protected request.
Review trusted proxy settings
Confirm that authentik trusts the proxy hop that sends it requests. If the trusted proxy configuration does not include your proxy addresses, authentik may read the proxy's IP as the client address, which affects logging, policies that depend on client IP, and redirect construction behind some setups. Check the trusted proxy or forwarded header settings in your authentik configuration and the matching settings in your proxy, including whether your proxy overwrites or appends forwarded headers. Make only the changes your environment requires, and recheck the redirect flow after each change. The check passes when a login from a browser completes, and the client address recorded in authentik logs matches the real user's address rather than the proxy's.
Capture outpost logs at the right level
When the earlier checks pass but requests still fail, capture outpost logs. Raise the log level only for the time needed to reproduce the problem, then reproduce it once with a single test login in a clean browser session. Collect the outpost container output and any relevant authentik server events for the same timestamp. Match the request path, status and the forwarded host in the log lines against what you saw at the proxy. Lowering the log level after the test keeps logs manageable, and logs may contain session and user data, so restrict who can read them. Confirm the procedure for setting the outpost log level and retrieving logs in your deployment, because the commands differ between Docker Compose and Kubernetes. The check passes when the log entry identifies which layer rejected the request.
Retest and record the fix
After you correct the failing layer, repeat the same test in a clean browser session and run the direct request to the outpost path again. Confirm that the protected application loads after login, that the user reaches the application without a loop, and that the forwarded headers reach the application. Then record the change, the symptom, and the layer that caused it in your runbook, and revert any temporary logging level. Ask your team to confirm that the same checks are part of the change record for future proxy or domain changes, since changes to proxy routes or external hostnames are the most common triggers for forward auth failures in existing deployments. The check passes when the test succeeds from two different browsers and the runbook entry is complete.
Questions teams ask before fixing forward auth
How long does diagnosing a forward auth problem usually take?
The time depends mostly on how many reverse proxies sit in front of authentik, how many applications share the outpost path, and whether your team can read outpost and proxy logs during the investigation. A single application behind one proxy with log access is usually a short exercise. Multiple proxies, several domains, and missing logs add rounds of testing because each change has to be checked against real browser sessions. Ask any provider to scope the work by proxy count, application count and log access before agreeing on a plan, and ask what they will do if the cause sits outside authentik, such as in the proxy configuration.
Can our own team fix forward auth problems without a consultant?
Often yes, if the team can reproduce the fault and has access to the authentik admin interface, the reverse proxy configuration and the outpost logs. Most forward auth faults come from a small set of causes: the /outpost.goauthentik.io path not reaching the outpost, a cookie domain that does not cover all protected hostnames, or proxy headers and trusted proxy settings that do not match the real network path. Teams that already run the reverse proxy and understand its routing are usually well placed to work through these. A consultant adds the most value when the layout is complex, the cause is intermittent, or the team lacks a second pair of eyes on the proxy and authentik configuration at the same time.
What should we prepare before asking a consultant to look at forward auth?
Prepare the material that shows how a request travels from the browser to the application. Useful items include:
- The reverse proxy configuration for each affected hostname, including the route for
/outpost.goauthentik.io. - Outpost logs and authentik server logs captured during a failed login, with timestamps and the affected hostname.
- A description of the domain layout: which hostnames are protected, whether the setup uses single-application or domain-level mode, and which cookie domain is configured.
- The trusted proxy and forwarded header settings, along with the network path between the proxy and authentik.
- Two or three test accounts with different group memberships, so access rules can be checked without using administrator accounts.
Agree on who will handle secrets in these files before sharing them, and redact keys and tokens first.
Do authentik upgrades change forward auth behavior?
They can. Changes to outpost behavior, cookie handling, default settings or proxy-related configuration may affect a working setup after an upgrade, so the release notes for every version between your current release and the target should be read before upgrading. Check the authentik release notes for breaking changes, and confirm that the outpost version matches the server version in your environment. The authentik security policy lists which versions receive security fixes, which helps you decide how quickly to move. If a forward auth problem began right after an upgrade, compare the notes against your proxy and outpost configuration before changing anything else.
When should we escalate a forward auth problem to authentik or the community?
Escalate once you have reproduced the fault, captured logs, and ruled out your own proxy and network configuration. Start with the authentik documentation and the troubleshooting guide for forward auth, then check the project's community channels for similar reports. If the problem appears to be a defect, include the authentik version, outpost version, a minimal reproduction and the relevant log lines. Commercial support tiers exist: the authentik pricing page lists ticket-based support for subscriptions over $1k, and dedicated support with SLAs as part of Enterprise Plus. Confirm the exact support terms with the vendor, since they determine response expectations, and do not assume a response window.
Does a fixed-scope engagement cover ongoing forward auth support?
A fixed-scope engagement covers the work agreed in writing, such as diagnosing a named set of applications, correcting the routing and cookie configuration, and documenting the result. Ongoing help after that falls under a separate arrangement. DeployOpen offers retainers for support, upgrades and continuous testing, so teams that expect frequent changes to applications or proxies can ask for that option. Your written scope should list the hostnames, proxies, applications and environments included, and state what happens if new faults appear during the work.
Which parts of the forward auth fix cost us time after the first change works?
The recurring effort comes from validating each new application and proxy route, rechecking cookie domains when hostnames change, and reviewing outpost logs after upgrades. The one-time effort is the initial mapping of routes, headers and trust settings. To keep recurring effort low, record the working configuration, store it in version control where possible, and add a test login for each protected application to your release checks. Ask any provider to separate one-time fixes from the checks and documentation your team will need to keep running.
Security risks when fixing forward auth quickly
Redirect loops and missing headers tempt teams to open the proxy, widen cookies or switch checks off. Each shortcut can turn a routing bug into an authentication bypass or a token leak, so the fix should be verified against the exact request path.
Loosening trusted proxy settings
Adding the reverse proxy or a broad IP range to the trusted list can end a loop quickly, but it also tells authentik to believe client-supplied forwarding headers. Before changing trust, confirm which hop actually sets X-Forwarded-For and X-Forwarded-Proto, and trust only that address or range. Re-test from outside the network to confirm a spoofed header does not change the result.
Widening the cookie domain
Setting the cookie domain to a parent domain shares the authentik session with every sibling host under it, including hosts you never meant to protect or that run less secure software. Use the narrowest domain that covers the applications in one forward auth scope. Check which hostnames can read the cookie after each change.
Exposing the outpost path too widely
Routing /outpost.goauthentik.io on every application or on a wildcard host gives unauthenticated clients a path into the outpost endpoints. In single-application mode only that path on the application domain should reach the outpost. Review proxy rules for catch-all location blocks that send the path to authentik on hosts that have no provider.
Leaking identity headers to untrusted upstreams
Forward auth passes user identity and group headers to the protected application, and the application usually trusts them without checking. If the proxy forwards these headers from a client request, or an upstream is reachable without going through the proxy, a user can impersonate another account. Strip inbound copies of identity headers at the proxy and allow the protected service to accept traffic only from the proxy.
Logging tokens while debugging
Verbose outpost or proxy logs can capture cookies, authorization headers or session identifiers while you trace a failed request. Those values can be replayed until the session expires. Enable debug logging only for the window needed, filter sensitive headers before sharing output, and reset the log level afterward. Treat collected logs as sensitive data.
Disabling checks without a rollback plan
Bypassing the forward auth check for one application to restore access removes the control silently for everyone who can reach that host. Record the change, the reason and the owner before making it, set a review date, and keep the previous proxy configuration ready to restore. Confirm that the protected application still refuses unauthenticated requests after the fix.
Using outpost logs to confirm the root cause
Once the route and cookie checks point in a direction, outpost logs are the fastest way to confirm which one is failing. The proxy outpost records each forward auth decision it makes, so a single request can show whether the outpost received the call, whether it recognized the application, and whether it found a valid session. Capture the logs at a detail level that shows those decisions without flooding the container with every internal message. The outpost logging documentation describes how to raise the log level for an outpost and where the output appears, so follow it for your deployment method (Docker Compose or Kubernetes) rather than guessing at settings.
Read the entries against the symptom you are chasing. A request that never reaches the outpost usually leaves no entry for the application at all, which points back to the reverse proxy rule for /outpost.goauthentik.io or to a domain-level path that is not routed. A request that reaches the outpost but is sent back to the login flow often shows a session check that failed, which is the signature of a cookie mismatch: the cookie was set on a different host or domain than the one the outpost validates against, or it was dropped by the proxy. Compare the host and cookie domain values in the log with the settings on the provider and the external URL. Confirm the exact field names and message wording in your running version, because outpost log output changes between releases and this guide does not reproduce them.
Treat verbose logging as a temporary diagnostic. Detailed outpost output can include request metadata and user identifiers, and it adds volume on busy proxies. Record the level you changed, reproduce the failure with one test user, copy the relevant lines into your incident notes, then restore the previous level and restart or reload the outpost as the documentation directs. Add a reminder to your change ticket so the setting is not left behind, and confirm after the restore that routine logs no longer contain per-request detail. Forwarding those logs to your central log platform is covered in the SIEM page.
How DeployOpen scopes and fixes authentik forward auth
DeployOpen treats a forward auth fault as a route, cookie and trust problem that can be traced end to end. We agree the written scope first, then reproduce the failing request, check each hop from the browser through the reverse proxy to the outpost, and document the fix so your team can repeat the check. Engagements are fixed-scope.
How we scope
- Inventory every application behind the proxy and whether each uses single-application or domain-level forward auth.
- Record the reverse proxy product, its configuration location, and who can change it during the fix.
- Agree in writing which symptoms are in scope, such as redirect loops, outpost path 404s or missing identity headers.
How we build
- Reproduce each failing request with the browser, proxy access logs and outpost logs side by side.
- Verify that the /outpost.goauthentik.io path reaches the outpost on every protected application domain.
- Check cookie domain, trusted proxy and header forwarding settings against the target topology, then test the corrected flow.
How we hand over
- Deliver a written record of each root cause, the configuration change made and the test that proves it.
- Provide a checklist your operators can run when a forward auth symptom returns after a change.
- Walk your platform and security staff through the outpost log settings and what each error pattern means.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
- Ask any quote to name which proxy, authentik version and outpost deployment the support covers.
- Confirm with your team how changes to proxy routes are approved before a retainer starts so fixes stay controlled.
