When authentik forward auth with HAProxy fits your estate
Choose authentik forward auth with HAProxy when HAProxy already fronts applications that cannot speak OIDC, SAML or LDAP, and you need authentik to decide who may reach them. Typical candidates are internal web tools, legacy dashboards and vendor appliances with a web interface but no native single sign-on. In this pattern, authentik documents a proxy provider type, and the proxy outpost is the component that performs the checks. HAProxy does not evaluate policy itself. For each request to a protected host, it asks the outpost whether the session is valid and which identity headers to pass upstream. If the outpost says no, the user is sent to the authentik login flow. Requests for the outpost's own paths, such as its callback and sign-out endpoints, must reach the outpost directly and never pass through the authentication check.
Compare this with the alternatives before committing. Native OIDC or SAML is preferable whenever the application supports it, because the application then holds its own session and claims and you avoid a header trust boundary. Another reverse proxy may be the better fit if your edge already runs Traefik, NGINX, Caddy or Envoy and your team operates that product well, since the authentik integration logic is similar but the configuration syntax and failure behavior differ. HAProxy tends to suit estates that already standardize on it for load balancing, TLS termination and health checks, where adding a second edge product would cost more than it saves. Confirm that your HAProxy version and build support the request and header handling this pattern needs, and check the supported authentik version line in the security policy before you lock the design.
Before you start, decide three things with your security team. First, whether each protected application will get its own provider or share a parent domain, because that choice drives cookie scope and policy granularity. Second, whether the application trusts identity headers, since any header the upstream accepts must be unreachable except through HAProxy. Third, which team owns the outpost, the HAProxy configuration and the authentik policies, and how changes move through review. Enterprise features such as mTLS client certificate authentication are listed as enterprise-only on the authentik pricing page, so confirm early whether your access model depends on them. Check the edition you need before design work begins.
Configuration choices and when each fits
This table compares the four main decisions in an authentik forward auth setup behind HAProxy: provider scope, outpost placement, trusted headers and TLS termination. Read each row as a choice you make once, with the access control trade-off and the version facts to confirm before you lock it in.
| Decision | Option and when it fits | Trade-off in access control | Confirm in your versions |
|---|---|---|---|
| Provider scope | Single-application provider for a few apps with different policies or owners | Narrow blast radius per app, but every new hostname needs its own provider and routing entry | Proxy provider behavior and cookie handling in your authentik release |
| Provider scope | Domain-level provider for many apps under one parent domain with shared policy | One login covers the whole domain, so a weak policy or misrouted host exposes every app beneath it | Cookie domain settings and how the outpost matches hostnames |
| Outpost placement | Embedded outpost inside the authentik server, for small estates with few proxy hosts | Fewer moving parts, but the outpost shares the server process and must be reachable from HAProxy | Whether the embedded outpost is enabled and its listening address |
| Outpost placement | Standalone proxy outpost near HAProxy, for separated networks or scaled outpost replicas | Keeps auth traffic on a defined path, but adds a deployment and token to rotate | Outpost image tag matching your authentik server version |
| Headers the backend trusts | Identity headers set by the outpost only, with HAProxy stripping any client-supplied copies | Prevents header spoofing, but a backend that trusts headers from any network path can still be impersonated | Header names the proxy outpost emits in your release and HAProxy header rules |
| Headers the backend trusts | Backend accepts identity headers only from HAProxy's address range | Limits trust to the proxy hop, but depends on a correct, stable network layout | Source addresses HAProxy uses to reach the backend |
| TLS termination | TLS ends at HAProxy, with plain HTTP to the outpost and backend on a private network | Simple certificate management, but the internal hop must be protected by network controls | Whether your security policy accepts unencrypted internal traffic |
| TLS termination | TLS re-encrypted from HAProxy to the outpost and backend | Protects internal hops and supports strict verification, with more certificate lifecycle work | HAProxy version support for the TLS options you plan to use and outpost TLS settings |
Setup sequence for authentik forward auth behind HAProxy
This sequence takes a team from a running authentik instance to HAProxy sending each protected request through the authentik outpost, with the signed-in user's identity passed to the backend. Each step ends with a check so that a failure is found before the next layer is added.
Create the proxy provider and application
In the authentik admin interface, create a proxy provider for each protected application and set its external host to the public hostname users will open. Choose forward auth in single application mode unless you have decided on domain-level mode, and bind the provider to an application with a clear name and launch URL. Attach the access policies or group bindings that decide who may reach the application. The step is done when the application appears in the library and the provider shows the expected external host, which you can confirm by opening the provider's details page.
Deploy or confirm the proxy outpost
Confirm that an outpost is running that serves the proxy provider. Use the embedded outpost for a small test, or deploy a standalone proxy outpost on the host or cluster that HAProxy can reach, following the authentik Docker Compose installation guide or the Kubernetes installation guide for your platform. Bind the provider to that outpost in the admin interface. The step is done when the outpost shows as connected in the Outposts list and its last-seen status is current. Confirm the version matches your authentik server, because outposts must track the server version.
Add the outpost path and auth check to HAProxy
For each protected backend, add a frontend rule that sends the outpost path (for example, the /outpost.goauthentik.io prefix) to the outpost backend without authentication. Then add an authentication check that sends a subrequest to the outpost for every other request, and denies the request, or redirects to the login flow, when the outpost answers unauthorized. Validate the configuration with the HAProxy syntax check before reloading, and keep the outpost backend on a private address. The step is done when the configuration validates and HAProxy reloads without errors. Confirm the exact outpost path and header names in the authentik proxy documentation for your version, since they vary by setup.
Map identity headers to the backend
Configure HAProxy to copy the identity headers that the outpost returns on successful checks, such as the username, email and groups, into the request sent to the protected application. Remove any headers with the same names that arrive from the client, so that a user cannot forge identity by sending them directly. Only pass the headers the application needs. The step is done when the headers are present in the request HAProxy forwards to the backend and the client-supplied copies are stripped, which you can confirm with a test request to a diagnostic endpoint or the application's request log.
Verify unauthenticated redirects
Using a private browsing session or an HTTP client without cookies, request the protected hostname. HAProxy should not return the application, and the client should be redirected to the authentik login flow for the application's external host. Also request the outpost path directly and confirm it responds without exposing protected content. The step is done when unauthenticated requests reach the login flow every time and no backend response is returned. If the redirect loops, check that the external host in the provider matches the hostname in the browser and that the cookie domain is correct.
Verify authenticated access and header values
Sign in as a user who is permitted by the application's policy, then load the protected application. Confirm the page loads through HAProxy and that the backend receives the expected user and group headers with the correct values. Then sign in as a user who is not permitted and confirm access is denied. The step is done when the permitted user reaches the application with correct headers and the unpermitted user is refused. Record the test results so the same checks can be repeated after each HAProxy reload or authentik upgrade.
Security considerations for HAProxy and the outpost
Forward auth moves the trust decision from each application to the proxy path and the outpost. The cards below cover the controls that keep that decision intact: what identity headers the backend will accept, whether the backend can be reached without HAProxy, how cookies and sessions are scoped, how traffic between HAProxy and the outpost is protected, and how security releases reach your environment.
Strip inbound identity headers
HAProxy must remove any identity headers a client sends before the outpost check runs, then add only the headers the outpost returns. If a request arrives with a forged user or group header and HAProxy passes it through, a backend that trusts headers can be fooled. Confirm with a test request that carries spoofed headers and check what the backend receives. Make sure the header names your HAProxy configuration deletes match the names authentik sets for the application.
Block direct access to the backend
Forward auth only protects an application if traffic cannot reach it without passing through HAProxy. Bind the backend to a private address or a network segment that only HAProxy can reach, and restrict the port with host or network firewall rules. Test from a host outside the proxy tier, including any internal network that can route to the application. A backend with a public or reachable port bypasses the check entirely.
Scope cookie domain and session lifetime
The outpost session cookie must cover the hostnames it protects and nothing wider. A cookie domain set to a parent domain shares the session with every sibling application, so a compromised or less protected service under that domain can receive it. Check the cookie domain, secure and http-only flags, and the session lifetime in the provider settings. Confirm that logging out in one application ends the session for the others you expect.
Encrypt traffic from HAProxy to the outpost
The check request from HAProxy to the outpost carries session cookies and returns identity headers, so it should use TLS when the outpost runs on another host or network segment. Decide whether the outpost is reached over an internal certificate, and verify the certificate chain in HAProxy's backend configuration rather than disabling verification. Confirm that the outpost port is not reachable from untrusted networks, since it is the component that issues the allow or deny decision.
Plan for the 24-hour security notice
The authentik security policy states that the project announces security releases at least 24 hours in advance. Your team should keep the HAProxy and outpost versions in step with the server and worker, and be ready to schedule a patch window within that notice. Check which versions currently receive security fixes and subscribe to the release feed. Also confirm that your outpost image tag is updated alongside the server, because a mismatch can break the forward auth handshake.
Differences for Docker Compose and Kubernetes hosts
The Docker Compose guide positions Compose for test setups and small-scale production, and it calls for a host with at least 2 CPU cores and 2 GB of RAM. On this model, the authentik server container runs core and an embedded outpost, a worker container handles background tasks, and PostgreSQL stores configuration and data. HAProxy usually runs on the same host or on a neighboring host that can reach the published port, so the outpost address HAProxy calls is typically a container port or a host-published port.
- Published ports: Confirm which host port the authentik server publishes and whether HAProxy reaches it through the host address, a Docker network alias or a bridge address.
- Shared network: If HAProxy runs in a container, attach it to the same Docker network as authentik or route to the host, and test that connection before writing ACLs.
- Embedded outpost: The server container includes the outpost, so the forward auth path can point there, but confirm your provider and outpost configuration matches the endpoint you chose.
- Single host limits: One host means one failure domain for HAProxy, authentik and PostgreSQL, which matters when the protected applications are production services.
- Bundled PostgreSQL: Compose ships PostgreSQL as part of the stack, so backup and restore of the database are your responsibility from day one.
Before relying on this setup, confirm the exact published ports, container names and network membership in your own Compose file.
The Kubernetes guide installs authentik with Helm. The chart bundles PostgreSQL, but the guide says that bundled database is for demonstration and test environments and recommends a separately managed PostgreSQL for production. In a cluster, HAProxy is usually outside the cluster or runs as an ingress layer, so the forward auth path must cross a Service boundary, and the outpost address is a cluster Service name or an externally reachable endpoint that you expose.
- Service exposure: Decide whether HAProxy reaches the authentik Service through a NodePort, a load balancer, an ingress controller or a private DNS name, and document which one you chose.
- Cluster DNS: If HAProxy runs inside the cluster, the outpost can be addressed by its in-cluster Service name, which is not resolvable from outside the cluster.
- Network policy: If your cluster enforces network policies, allow traffic from HAProxy's source to the authentik Service and its outpost port.
- Managed PostgreSQL: Plan a separately managed database for production, with its own backup, failover and connection limits.
- Replicas and sessions: Multiple replicas change where a request lands, so verify that login redirects and session cookies work across them.
Confirm the Service type, the reachable address HAProxy uses and the network policy rules with your cluster team before testing the auth path.
HAProxy performs the forward auth check by sending a subrequest to the outpost and acting on the response. That means the outpost endpoint must be reachable from HAProxy with low latency and stable addressing on every request, not only from a browser. Moving from Compose to Kubernetes changes that path, so the network design should be written down before ACLs are built. Note that authentik's outpost also has to reach the authentik server to validate sessions and fetch configuration.
- Source address: Identify the address HAProxy presents to the outpost, since NAT or a load balancer can hide it and affect logging.
- Two-way paths: Confirm the outpost can reach authentik and HAProxy can reach the outpost, and test both directions.
- Firewall rules: Open only the outpost port between HAProxy and authentik, and keep the authentik admin interface off the public path.
- Redirect host: Users are redirected to the external authentik URL, so that hostname must resolve and terminate TLS for browsers, even when internal calls use a private address.
- Failure behavior: Decide what HAProxy does when the outpost is down, and test that protected backends fail closed.
What your team must confirm is the path, the ports and the external hostname for your environment, not the values shown in any example.
Limits to confirm in your environment
Forward auth with HAProxy depends on four things that vary by environment: the authentik release line you run, the HAProxy build and the auth check method it supports, how the protected application handles injected headers, and which licensed features you need. Confirm each one before you write the first HAProxy configuration.
Which authentik release line will you run?
The authentik security policy lists 2026.5.x and 2026.8.x as the versions receiving security fixes, and the project announces security releases at least 24 hours in advance. Confirm that your target version sits on one of those lines and plan a path to move when a line falls out of support. Check the release notes for each version you pass through, since upgrades must follow the sequence the project publishes. Also confirm that your server and worker containers run the same version as your outpost image.
Does your HAProxy build support the auth check?
HAProxy does not have a single built-in forward auth directive, so the design usually relies on an outpost path, a backend that sends an authentication subrequest, and rules that copy response headers to the application. Confirm which HAProxy version and build you run, whether it includes the Lua or SPOE features your chosen pattern needs, and whether your distribution or appliance vendor supports that configuration. Test the check against a staging listener before changing production traffic.
Can the application accept injected identity headers?
Forward auth passes user identity to the backend as HTTP headers, so the application must either trust those headers or ignore them. Confirm that the application does not read identity from client-supplied headers when no proxy is present, and that it can be reached only through HAProxy. Ask whether its session handling conflicts with the outpost cookie domain, and whether any API clients will break when the proxy redirects unauthenticated requests to a login page.
Do you need Enterprise features such as mTLS?
The Open Source edition is listed as free, with community support through Discord only. Enterprise-only features on the pricing page include mTLS client certificate authentication, enhanced audit logging, password history and ticket-based support. If your access policy requires client certificates at the proxy or audit records of every decision, confirm that need now, because it changes both licensing and the support model. The Enterprise license also applies only to code in the enterprise directory, so confirm which terms cover your deployment.
Where will the outpost run and reach authentik?
The outpost must reach the authentik server over the network, and HAProxy must reach the outpost on the path it uses for checks. Confirm the hostnames, TLS trust chain and firewall rules between HAProxy, the outpost and authentik in each environment. Check whether the embedded outpost or a standalone proxy outpost fits your topology, and whether the outpost token rotates on a schedule you can support.
Questions teams ask before protecting apps with HAProxy and authentik
What drives the cost of protecting apps with HAProxy and authentik?
The cost follows from the number of applications, how many HAProxy frontends and backends are involved, how many hostnames and cookie domains must be handled, and how much of the authentik deployment is new. Effort rises when applications use different hostnames, when some paths must stay public, or when the proxy outpost has to run in more than one environment. Each engagement is fixed-scope, so the quote comes from a written list of applications, routes and deliverables. Ask for the quote to separate one-time design and configuration work from any recurring support or upgrade retainer. DeployOpen does not publish a price list, and a quote follows from the written scope.
How long does a forward auth project with HAProxy usually take to scope?
The duration depends on the number of applications, the state of the existing HAProxy configuration, and whether authentik is already running. A scoping discussion produces a written scope with deliverables and timelines, and that document is what the team should compare against its own capacity. DeployOpen does not publish fixed durations for this work, so ask for the timeline as part of the written proposal and check that it lists the environments, testing and handover steps included.
What must our team provide before work starts on HAProxy and authentik?
Plan to provide access and information in four areas:
- Read and change access to the HAProxy configuration, including the frontends, backends and any existing auth rules, on a test copy first.
- A list of applications with their hostnames, paths that must stay public, and any headers each application expects.
- DNS control or a change process for the hostnames that authentik and the protected applications will use.
- TLS certificates or the ability to issue them for each hostname, plus the cookie domain decisions that follow from them.
Can our internal team set up HAProxy forward auth with authentik alone?
Yes, a capable internal team can do it alone if it already operates HAProxy and has someone who can run authentik. The work involves a provider and application per protected service, an outpost reachable from HAProxy, routing rules for the outpost path, and checks that the right identity headers reach each backend. Teams without recent HAProxy or identity experience usually find the testing and edge cases take longer than the configuration itself. A fixed-scope engagement can cover design, build and handover, or it can be used as a review of work the internal team has already done.
Which authentik features does the open-source edition leave out?
The Open Source edition is free and its support is the community Discord. According to the authentik pricing page, Enterprise-only features include Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history, enhanced audit logging and ticket-based support for subscriptions over $1k. Enterprise Plus adds dedicated support with SLAs, multi-instance deployment support and FIPS compliance for FedRAMP requirements. Forward auth through the proxy outpost is part of the core product, but confirm each feature your design depends on against the pricing page and the license in the enterprise directory before you commit.
Does the HAProxy forward auth setup need a separate outpost for each application?
Not necessarily. The design choice is between one provider per application and one provider for a parent domain, and that choice changes how many outpost routes, cookie settings and policies you maintain. Confirm the outpost deployment model against the authentik providers documentation before you finalize the HAProxy routing plan, because the number of outposts and where they run affects latency and failure handling.
What happens if the authentik outpost goes down behind HAProxy?
Requests that depend on the outpost check fail, so protected applications become unreachable or redirect users to a failing login path. Plan health checks for the outpost, a clear fallback behavior for the HAProxy backend, and monitoring that alerts before users notice. Test the failure path in a staging environment and record the expected behavior so operators know what a user sees during an outage.
How DeployOpen scopes and delivers HAProxy forward auth
DeployOpen scopes authentik forward auth with HAProxy as a fixed-scope piece of work agreed in writing before any change is made. We build the outpost path, auth checks and identity headers in your own environment, then test and document each route before handing it over.
How we scope
- Inventory the applications behind HAProxy and classify which ones can use forward auth versus native OIDC or SAML
- Agree which hostnames, outpost paths and backends are covered, and which are excluded from the written scope
- Confirm the authentik version, deployment method and outpost placement, and record them in the written scope
- Define the acceptance tests for login redirects, logout, header delivery and denied access before work starts
How we build
- Configure the HAProxy frontends and backends that route the outpost path and protected application traffic
- Set up the authentik proxy provider and application objects that match each protected hostname
- Pass the authenticated user and group headers to backends and strip any client-supplied copies of those headers
- Test each route with signed-in, signed-out and unauthorized sessions, including redirects and cookie scope
How we hand over
- Deliver the HAProxy configuration, authentik provider settings and a per-route access matrix as versioned files
- Document the header contract so backend application owners know which identity values they can trust
- Run a handover session covering troubleshooting steps for redirect loops, missing headers and outpost connectivity
- Record the test results and the open items that remain with your team after delivery
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope delivery
- Plan retests of forward auth routes when authentik or HAProxy versions change, following the scope agreed in writing
- Ask your team to confirm supported versions and release timing with the authentik security policy before scheduling upgrades
