Why teams use the authentik proxy provider for apps without native SSO
Many internal and legacy applications cannot speak OIDC or SAML at all. They expect a username from the request, or they have no login of their own. The authentik proxy provider lets a reverse proxy enforce authentication through authentik before a request reaches the application, and then pass the verified identity upstream in request headers. That gives these applications single sign-on without changing their code, which is usually the only realistic path for a vendor appliance, an old dashboard or an in-house tool nobody can safely modify.
The approach is harder than it looks because the proxy becomes a trust boundary. The application will believe whatever identity headers arrive, so anyone who can send a request that skips the proxy, or inject their own headers through it, can impersonate any user. Before rollout, the team needs to decide which headers the proxy sets, which inbound headers it strips, and how the application is configured to read them. Those decisions belong in version-controlled proxy configuration that someone reviews, not in a one-time edit on a server.
Every route needs an explicit decision. A forward auth setup usually covers a hostname, but paths such as health checks, static assets, webhooks, API endpoints and login callbacks may need different treatment, and some should bypass authentication for a documented reason. Teams should list each route, its owner, whether it requires a session, and what identity it receives. The most damaging mistake is an unlisted path that the proxy serves without checking authentication, so the route inventory is a control, not paperwork.
The application must never be reachable while bypassing the proxy. Network policy, firewall rules, bind addresses or container networking should ensure that only the reverse proxy can open a connection to the app. Confirm this from outside the trusted network and from inside a different segment, because a direct port that works is a complete authentication bypass regardless of how well the proxy is configured.
The proxy provider is one of several authentik provider types, alongside OAuth2/OIDC, SAML, LDAP, RADIUS and others. It is the right tool only for applications that cannot integrate natively. The work described here sits alongside the wider SSO rollout rather than inside it: the core deployment, directory sources, MFA policy and native integrations are planned separately. Confirm with your own environment which applications truly need the proxy path before committing to it, and confirm the exact proxy and outpost behavior for your authentik release and your chosen reverse proxy against the current provider documentation.
Which authentik components forward auth depends on
Forward auth is a chain of cooperating parts rather than a single service. Each part has a clear job, and a fault in any one of them can block logins or leave an application unprotected.
The authentik server container
The server container runs authentik core together with an embedded outpost, and the outpost is the piece that answers proxy requests from your reverse proxy. Per the architecture documentation, this container is where the proxy decision is made for each incoming request. Check that the server container is reachable from the reverse proxy on the network path you plan to use, and that its health is monitored separately from the application behind it.
The authentik worker container
The worker container runs background tasks, separate from the request path handled by the server. Work such as sending emails, applying scheduled jobs and other asynchronous tasks happens here. For forward auth, a stopped worker does not usually stop logins outright, but it can delay work that users and administrators depend on. Confirm in the architecture documentation for your release which tasks depend on the worker, and alert on it as its own service.
PostgreSQL as the single data store
The architecture documentation states that PostgreSQL stores all configuration and data except uploaded files. That includes providers, applications, users, and session state, so the database is on the critical path for every protected request. Decide early whether PostgreSQL is hosted by your team or a managed service, and plan its backup and restore, because losing it means losing the configuration that defines your access rules.
Application provider and outpost binding
The proxy provider defines how a given application is protected, and the application object in authentik links that provider to a hostname and a path. The outpost then has to be bound to the provider so that it serves the requests for that application. The exact binding steps and naming differ between releases, so confirm the wiring against the current provider documentation for the release you run before you rely on it.
The reverse proxy as enforcement point
NGINX, Traefik or Caddy is where your team decides which requests reach the application at all. The proxy sends each request to authentik for an access decision and passes identity headers upstream only when access is granted. Because this configuration is written by your team, a missing or mis-scoped auth rule leaves an application open regardless of how authentik is set up. Review the proxy configuration as carefully as the authentik policies.
The protected application and its headers
The protected application receives identity through headers set by the reverse proxy, not through its own login. That makes header trust a design decision: the application must only accept identity headers from the proxy, and the proxy must strip any client-supplied copies of those headers. Test both behaviors with a request that carries forged headers, and confirm which header names your release sets before you write application code against them.
Proxy mode or forward auth mode: which fits your application
This table compares the authentik proxy provider modes against how each application is addressed and whether it handles login itself. Find the row that matches your hostnames, identity needs and path layout, then check the operational cost and main risk in the last two columns. Confirm mode names and exact behavior in the authentik providers documentation before you commit to a design.
| Situation | Mode that usually fits | Operational cost | Main risk to control |
|---|---|---|---|
| Single application on its own hostname | Forward auth for a single application, with one provider per hostname | One DNS record and one certificate for the hostname. The session cookie stays scoped to that host. | A route missing from the proxy config leaves the hostname reachable without the gate. |
| Several applications under one parent domain | Domain-level forward auth with one shared cookie domain | Cookie domain must be set deliberately. A wildcard certificate may simplify certificates if your CA and DNS allow it. | Applications added later under the same parent domain may be gated by default or missed. |
| App needs the authenticated user identity inside the app | Proxy mode, or forward auth that copies identity headers to the upstream (confirm which mode sets them) | The app must trust identity headers only from the proxy. Strip client-sent copies of those headers at NGINX, Traefik or Caddy. | Header spoofing if the app can be reached directly, such as on a published port or internal network path. |
| App already handles login and only needs a gate | Forward auth, so authentik controls access and the app keeps its own login | Align session lifetimes and logout between authentik and the app to avoid repeat prompts. | Logout in one place can leave a live session in the other, so users stay signed in unexpectedly. |
| Internal tools reached by path under one host | Forward auth applied to specific path prefixes in the proxy configuration | Each protected path needs its own route rule, and rules grow with every tool. Confirm how your proxy matches paths. | A tool served on a new or legacy path without a matching rule is open to anyone who can reach it. |
How to set up authentik forward auth behind NGINX, Traefik or Caddy
This sequence takes a team from an empty host to an application that only reachable users can open, with authentik deciding access and passing identity headers upstream. Each step ends with a check, so a failure can be traced to the step that introduced it.
Provision the authentik host
The platform team provisions a Linux host or virtual machine inside its own infrastructure and deploys authentik with Docker Compose for a test or small-scale setup. The authentik Docker Compose guide calls for at least 2 CPU cores and 2 GB of RAM, so size up for expected user load. Plan PostgreSQL as a separately managed service for anything beyond a test setup, which matches the authentik Kubernetes guide's production advice. Done when the administrative interface loads over the internal address, the server and worker containers report healthy, and an administrator can sign in.
Create the proxy provider and application
In the authentik administrative interface, the administrator creates a proxy provider and sets its mode to match the reverse proxy, either proxy or forward auth, after confirming which mode the chosen proxy supports in the current docs. Enter the external hostname that users will browse to, then create an application linked to the provider. Bind the provider to the embedded outpost or a dedicated outpost. Done when the outpost shows as connected in the administrative interface and the provider lists the application.
Create the proxy hostname and certificate
The network team creates a DNS record for the protected hostname that points to the reverse proxy, then issues a TLS certificate for that name from the internal certificate authority or an ACME process, following the organization's certificate policy. The external hostname in authentik must match the scheme and name that browsers use, or redirects will fail. Done when a request to the hostname over HTTPS returns a certificate that covers the name and the chain validates on a client that trusts the authority.
Configure the reverse proxy forward auth
The platform engineer configures NGINX, Traefik or Caddy to send an authentication subrequest to the authentik outpost for every request to the protected hostname. The proxy must redirect unauthenticated users to the authentik login flow and copy the identity headers from the authentication response onto the upstream request. Endpoint paths, header names and directive syntax change between releases, so confirm the exact directives for each proxy against the current authentik documentation for the release in use. Done when an unauthenticated request to the application returns a redirect to the login flow instead of the application content.
Restrict the upstream app to the proxy
The platform engineer binds the upstream application to a private address or localhost and uses host firewall rules or network policy so that only the reverse proxy can reach its port. The proxy should overwrite any identity headers a client sends, so users cannot forge them. The application should trust identity headers only from the proxy. Done when a direct connection to the upstream port from another host fails, and a request through the proxy that includes a spoofed identity header reaches the application with the header replaced by the authenticated value.
Test three user states
The tester runs three cases against the protected hostname. A logged-out user should be redirected to the authentik login flow. A logged-in user who belongs to the required group should reach the application, and the application logs should show the identity header that authentik passed. A user without the required group should be denied, which the administrator enforces by binding a group policy to the application. Done when all three cases produce the expected result and the outcomes are recorded with the configuration so the team can repeat the tests after upgrades.
How identity headers reach the upstream app safely
After authentik has authenticated a user through the proxy provider, the outpost sets identity values on the request before it reaches the protected application. Typically these include the user's name, email address and group membership, carried as HTTP headers. The application does not check a password or session itself. It reads these headers and trusts them. That trust is the whole model, so the design question is not whether headers work but whether the application can only ever receive them from the path you intended. Treat the header set as an interface between two systems and document it as one.
The first control is network and proxy placement. The application must accept identity headers only from the reverse proxy or outpost that sits in front of it, never from a client directly. If the application is reachable on a port or address that clients can hit, anyone can send a request with a forged user or group header and the application will believe it. Restrict the upstream listener to the proxy's network path. Then configure NGINX, Traefik or Caddy to remove any client-supplied copies of the identity headers before the request is forwarded, so that only values set by the outpost survive. Test this explicitly by sending a request with your own identity headers from outside the proxy and from a logged-in session, and confirm the application ignores them.
The exact header names and the list of attributes sent are settings you must confirm, not assume. Read them from the proxy provider configuration in your authentik version and from the release documentation for the release you run, because the set of headers forwarded and how user attributes are mapped to them can change between releases. Do not copy header names from a blog post or from another deployment. Write the confirmed names into your reverse proxy strip rules and into the application's trust configuration in the same change, so the strip list and the accepted list cannot drift apart. Record the release version next to them so an upgrade prompts a re-check.
Map only the attributes the application actually uses. Each additional attribute widens what the application receives and what a compromised upstream could learn, and it adds a field that must be kept accurate in the directory. For most applications this means a stable unique username, an email address if the app displays or notifies, and the groups the app needs for role decisions. Property mappings in authentik control which values are built into the outgoing identity, so review them as code and keep them minimal. Confirm which attribute is used as the identifier, since changing it later can orphan existing application accounts.
Group-based access belongs on the authentik side. Decide which groups grant access to which application through the application's policy bindings, so users outside those groups are refused before any request reaches the app. The application may still read group headers for role decisions, but it should not be the first place access is enforced. Keep group names stable and documented, because the application will compare against them literally. Ask your identity team to confirm which group attributes are forwarded and whether nested group membership is flattened, since that determines what the application sees for users in several teams.
Hardening the proxy path so identity headers cannot be spoofed
A proxy provider only holds up if nothing can reach the protected application around the proxy and no client can supply its own identity headers. The cards below cover network placement, header handling, transport, access policy, outpost credentials and change review, which together form the trust boundary between the reverse proxy and the application.
Keep the application on a private network
The protected application should listen only on a private network that the reverse proxy can reach, never on a public interface. If a client can connect to the application directly, it can send identity headers that the application will trust. Check the bind address, container port publishing and security group or firewall rules for each protected service, and confirm that only the NGINX, Traefik or Caddy host can open the upstream port.
Strip inbound identity headers at the proxy
Configure the reverse proxy to remove any identity headers sent by clients before forward auth adds its own values. Header names depend on the provider configuration, so copy them from the authentik proxy provider settings rather than from memory. Test the result by sending a request with forged headers to a public route and confirming the application sees only the values authentik set after authentication.
Enforce TLS on the public hostname
Serve every protected hostname over HTTPS and redirect plain HTTP before any authentication step runs. The session cookie and the forwarded identity depend on the browser-to-proxy channel, so a downgrade or a mixed-content path weakens both. Confirm the certificate chain, the redirect behavior on the login and callback URLs, and that the cookie domain and secure flags match the public hostname.
Bind access policies to each application
Attach an access policy to each proxy-protected application and bind it to the groups allowed to use it, instead of relying on a broad default. Then sign in as a user who is not in any bound group and confirm that access is denied at the proxy, not only hidden in the interface. Repeat the test after group membership or policy changes, because a policy that appears correct on paper can still allow the wrong users.
Require MFA for administrative access
Administrators of authentik control the providers, outposts and policies that decide who reaches protected applications, so their accounts are the highest-value target in this setup. Enforce multi-factor authentication for every administrative group through the authentication flow, and review which stages apply to admin sign-in. The flow and policy review itself is covered in the authentik security hardening topic, so use that topic for the detailed steps.
Rotate and vault outpost tokens
The outpost that serves forward auth connects to authentik with a token, and anyone holding that token can impersonate the outpost. Store the token in a secrets manager, inject it into the proxy deployment at runtime, and rotate it on a schedule your team can actually follow. After each rotation, confirm that the outpost reconnects and that the old token no longer works. Ask your platform team which secrets manager and rotation tooling they already run before choosing the method.
Review proxy rules when routes change
Every new route, hostname or path exposed through the proxy is a new entry point for identity headers and a new place where a policy can be missed. Add a review step to the change process for any route that touches a proxy-protected application, covering the upstream address, the header handling and the bound policy. Check that the route is still reachable only through the proxy after the change, and record the reviewer in the change ticket.
Act on security releases quickly
The authentik security policy lists the supported version lines that receive security fixes, and the project announces security releases at least 24 hours in advance. That window is short, so your team needs a named owner, a staging environment and a documented way to schedule the upgrade of both the server and the outpost. Confirm which release lines you are on against the security policy, and check that the proxy and the server versions stay compatible after each upgrade.
How to test that forward auth works and fails closed
Forward auth is only worth deploying if the team can show that it denies access by default and that the application never sees identity it has not earned. Test the proxy provider in authentik before any user depends on it, and treat each check below as a pass or fail result with a recorded outcome. Start with the anonymous case: request a protected route in a private browser session and confirm that the reverse proxy (NGINX, Traefik or Caddy, depending on your build) hands the request to the authentik outpost and redirects to the login flow. The response must not contain any application content. Confirm the exact redirect target and status code in your own environment, because they depend on the proxy provider's external host, the outpost address and the hostnames you chose.
Next, test the trust boundary between the proxy and the application. Send a request straight to the proxy with forged identity headers such as the username, email or group headers your application reads, and confirm that the outpost overwrites or strips them before the request reaches the app. Then send a request directly to the upstream application address, bypassing the proxy entirely. This should fail at the network level or at the application's own listener. If it succeeds, the application is reachable around the proxy and the header model cannot be trusted. Check the header names against the documentation for your proxy provider mode and version, since the names the app expects are a configuration decision you own, not a default you can assume.
Then test authorization and session behavior with real accounts. Sign in as a user who is outside the permitted group or the policy binding for the application, and confirm access is denied with no partial content. Sign in as a permitted user, confirm the application receives the expected identity values for that user, and compare them with the directory record. Next, shorten or wait out the session lifetime that applies to the application and confirm the next request forces re-authentication. Finally, log out through the flow you provide and confirm that a replayed session cookie no longer grants access. Record which session and cookie settings govern each step, because expiry behavior depends on the configuration you set, not only on the defaults.
The most important test is the failure case. Stop the authentik server container deliberately, leaving the reverse proxy running, and send requests to a protected route. The expected result is denial or an error page, never unauthenticated content reaching the application. Then restore the server and confirm access returns only after valid sign-in. Run the same test with the outpost unreachable if your topology separates it from the server. A proxy that serves traffic when its auth backend is down is a fail-open configuration, and it should block the rollout. Also confirm that your proxy's own failure handling is not configured to pass requests through on auth errors.
Keep the evidence in a form an auditor or a second engineer can follow: the test date, the authentik and proxy versions under test, the request and response for each case with headers and redirect targets, the user and group used, the session settings, and the stop and restart timestamps for the failure test. Store the results with the configuration in version control so a later change can be re-tested against the same cases. Ask your team or partner to confirm, in writing, which cases are in scope and what pass criteria apply before the test run starts, so that the results can be reviewed later without argument.
What drives effort and cost for the proxy provider rollout
This table lists the factors that change the size of a proxy provider rollout, the direction each one pushes effort, and how to keep it down. The party column shows whether internal staff or an outside partner usually carries each item, and a quote follows from a written scope that confirms these counts.
| Driver | Effect on effort and cost | How to keep it down | Who pays |
|---|---|---|---|
| Protected applications and routes | Each app without native SSO needs its own provider, outpost binding, route and test. Effort grows with every extra route, including admin paths and health endpoints. | Inventory apps first, retire unused ones, and group routes that share one access rule. | Internal staff for inventory, partner or internal for build |
| Hostnames and certificates | Each distinct hostname adds a DNS record, a certificate, a proxy server block and a redirect URI to check. Wildcard or shared certificates reduce renewal work. | Consolidate apps onto a shared domain with path or subdomain patterns and use one certificate issuance process. | Internal staff for DNS and certificates |
| Reverse proxy already in place or new | An existing NGINX, Traefik or Caddy setup reuses known config and tooling. A new proxy adds platform build, hardening and operations work. | Choose the proxy your team already runs and standardize one forward auth snippet for all routes. | Internal staff if existing; partner or internal if new |
| Apps needing group-based rules versus a single gate | Per-group authorization needs group mappings, policy bindings and tests for each role. A single gate for all signed-in users needs far less configuration. | Start with one gate for the whole group of apps, then add group rules only where a documented access requirement exists. | Internal staff to define access rules; partner to configure |
| Environments (test, staging, production) | Each environment repeats outpost setup, hostnames, certificates and tests. Drift between them is a common source of rework. | Keep proxy config and authentik blueprints in version control and promote the same files through each environment. | Internal staff for promotion; partner for initial setup |
| Upstream apps locked to the proxy network | If upstream apps accept traffic from any network path, bypassing the proxy is possible. Restricting them to the proxy network or host adds firewall and network changes, which often need security and network team sign-off. | Confirm the network path early, restrict upstream ports to the proxy, and test a direct request that should fail. | Internal network and security teams |
| PostgreSQL hosting choice | The authentik docs say the chart's bundled PostgreSQL is for demonstration and test use and recommend a separately managed PostgreSQL for production. A managed or self-run database adds backup, patching and connection planning. Ask the vendor to confirm connection requirements for your release. | Decide hosting before build, reuse your existing database standards, and include backup and restore tests in scope. | Internal platform or DBA team; partner if in scope |
| Testing and evidence for access review or compliance assessment | Assessors expect records of who can reach each app, how access was approved and tested, and that changes were logged. Gathering this evidence takes effort for each app and each environment. Note that DeployOpen prepares evidence but does not issue audit reports. | Define the evidence list at scope time, export access and config records from the start, and test the proxy block for each route. | Internal compliance and app owners; partner for test and evidence preparation |
What to monitor, upgrade and document after go-live
Recurring monitoring for the proxy provider should cover four areas: the authentik server and worker containers, PostgreSQL, proxy logs and certificates. Confirm that both containers are running and responding. The worker handles background tasks, and a stalled worker can delay work the proxy depends on without any obvious error on the login page. PostgreSQL needs the closest watch. The authentik 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading, because authentik no longer uses Redis and moved caching, tasks, sessions and WebSocket functions into the database. Track connection counts against the limit your database is configured for, and alert well before that ceiling. In the reverse proxy layer (NGINX, Traefik or Caddy), watch for bursts of 401 and 403 responses, which often point to a changed group membership, a broken session or a misconfigured route.
Back up the PostgreSQL database on a schedule, because it stores all authentik configuration and data except uploaded files. Pair those backups with a configuration export so providers, applications, outpost bindings and flows can be rebuilt if a rebuild is ever needed. Restores are the evidence that matters, so schedule a test restore at a set interval and record the result. A successful backup job alone does not show that the data can be recovered. The proxy outpost must also stay on a version compatible with the authentik release running the core. After each server upgrade, check that the outpost image matches the server version, then redeploy the outpost container if it does not. Confirm the compatibility guidance in the release notes for your exact versions before the change window opens.
The authentik security policy names 2026.5.x and 2026.8.x as the supported release lines that receive security fixes, and the project announces security releases at least 24 hours in advance. Plan a standing upgrade window that moves each environment between these lines before the older line leaves support, and record which line each environment runs. The GitHub releases page showed 2026.8.4, published October 14, 2026, as the latest release at the time of the source check, so confirm the current list on the security policy page before you schedule work. A 24-hour notice is short. Your upgrade runbook should name who can approve an emergency patch, who redeploys the outposts behind each protected application and how the proxy is checked afterwards.
Hand over documentation that lets the next operator change a gated application without rediscovering how it was built. The route inventory lists each hostname and path the proxy protects, the provider behind it and the environment it belongs to. Record which applications are gated and which group grants access to each one, so access reviews can start from group membership and work outward. The header contract for each app lists the identity headers passed upstream, the attributes that fill them and whether the application accepts those headers only from the proxy. Document where the outpost token is stored, who may rotate it and the steps to do so, without placing the token value in the document. Finally, attach the verification evidence: the requests tested, the expected and observed status codes, the authentik version under test and the date each test was run.
What buyers and engineers ask about authentik forward auth
What drives the cost of an authentik forward auth engagement?
The main cost drivers are the number of applications and routes to protect, how many environments need the work (for example test, staging and production), and how much of the reverse proxy configuration already exists. Each route needs its own decisions on which headers to pass upstream and which groups may reach it, so a larger set of routes means more design, configuration and testing. Ask for a quote that lists each environment, each application and the proxy in use, and that separates one-time build work from any recurring support. DeployOpen does not publish a price list; a quote follows from the written scope. Your own costs are the proxy team's time, DNS and certificate changes, and the application owners' time for testing and decisions. Product licensing is a separate question covered below.
How long does it take to set up authentik forward auth?
The duration depends on the number of applications, routes and environments, the state of your reverse proxy, and how quickly app owners decide header and group mappings. Applications that share one pattern usually go faster than apps with unusual paths, websockets or custom authorization. Plan for a test window in each environment before production cutover. No fixed duration applies to every estate, so ask for a timeline in the written scope that ties each phase to a named set of applications and an agreed test window.
What must our team provide before forward auth work starts?
Your team needs to provide access to the reverse proxy (NGINX, Traefik or Caddy), control of the DNS records for protected hostnames, certificates for those hostnames, and a test window in each environment. App owners must decide which identity headers their application should trust and which authentik groups may access it. Your team also needs a place to run authentik, with PostgreSQL and hosting arranged in advance. Confirm these items with your own infrastructure owners before the scope is signed, because missing access is the most common source of delay.
Can our own team set up authentik forward auth without a partner?
Yes, for a small set of applications when your team already runs the chosen reverse proxy and understands its configuration. Forward auth involves proxy rules, the authentik provider and outpost settings, header handling and testing of logout and session behavior, so the work is manageable for a team with those skills and a short list of apps. A partner helps most when many applications must be onboarded, several environments must stay consistent, the proxy configuration is complex or shared, or the team lacks time for testing and documentation. Assess your own proxy skills and application count before deciding.
Does the authentik proxy provider require an Enterprise license?
The proxy provider features this topic relies on are marked as Open Source on the authentik pricing page, so they do not depend on an Enterprise subscription. The pricing page does list Enterprise and Enterprise Plus features, and Enterprise code lives in a separate license directory in the repository. Edition details change over time, so confirm the current feature list and license terms on the pricing page and in the repository license before you rely on them. Also confirm which features your design needs, such as any directory integration or audit logging you plan to add later.
Is authentik forward auth work offered as a fixed-scope engagement?
Most DeployOpen engagements are fixed scope, with scope, deliverables and timelines agreed in writing before work starts. For forward auth, the written scope should list the applications, the reverse proxy, the environments, the header and group decisions, the test windows and the documentation to be handed over. Changes to the application list or to proxy behavior after signing should go through a change process that updates the scope and quote. Ongoing support, upgrades and continuous testing are available as separate retainers.
What does the engineer need to check after forward auth goes live?
Engineers should verify that unauthenticated requests redirect to login, that authenticated users reach only the routes their groups allow, and that the identity headers arrive upstream with the expected values and that applications ignore spoofed headers from clients. Test logout, session expiry and websocket or long-running connections on each protected route. Confirm that the proxy strips identity headers from incoming client requests and that the outpost can reach the authentik server, and document the authentik version and the supported release line in use.
Which authentik versions should I plan forward auth against?
Plan against a version on a supported release line, and confirm the current list on the authentik security policy page, which names the supported year.month lines that receive security fixes. The GitHub releases page shows the latest release, and authentik announces security releases at least 24 hours in advance. Choose one version for the build, record it in the scope, and plan a test window for future upgrades, including outpost compatibility with the server.
How DeployOpen scopes, builds and hands over authentik forward auth
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For authentik forward auth, that means a written scope covering the proxy provider, the reverse proxy in front of each protected application, and the header-based identity passed upstream, delivered within the client's own cloud accounts, data centers or air-gapped networks.
How we scope
- The written scope lists each application to protect and whether it runs in proxy or forward auth mode.
- It names the reverse proxy in use, such as NGINX, Traefik or Caddy, and where each proxy runs.
- It defines which identity headers each upstream application must receive and how it reads them.
How we build
- Build covers the authentik proxy provider, outpost placement, and routing rules for each protected hostname.
- Proxy configuration is written so that the reverse proxy strips and sets identity headers consistently.
- Testing checks login, logout, session expiry and access denial for users outside each permitted group.
How we hand over
- Handover includes configuration files, provider and outpost settings, and a per-application access matrix.
- Runbooks describe how to add an application, rotate outpost tokens and roll back a proxy change.
- Clients receive test evidence showing which header values reach each upstream and which requests are denied.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask in any quote how upstream authentik release lines and outpost upgrades will be covered during support.
