Single-application forward auth in authentik: when one provider per app is worth it
Many internal applications cannot speak OIDC or SAML, so they have to sit behind an authentik proxy outpost that checks each request before it reaches the application. The decision you face is between per-application policy control and fewer providers with shared sign-in. Single-application forward auth favors control, and domain-level forward auth favors fewer moving parts. Choose before you publish the first route, because changing the mode later means reworking cookies, redirects and bindings for every app.
In single-application mode, each application gets its own proxy provider, its own policies and its own bindings. The forward auth documentation describes this mode as routing only /outpost.goauthentik.io on the application's domain to the outpost. Teams usually need this mode when applications hold different sensitivity levels, when only some groups should reach a given tool, or when an auditor expects access decisions to be traceable to one application. Confirm the exact routing rules for your reverse proxy against the forward auth guide before you copy them.
Domain-level mode uses one authentication URL and a shared cookie domain for many applications. Users authorize once and then move between the applications under that parent domain without a new prompt for each one. The trade-off is that individual applications cannot carry separate application-level policies, so every app under the shared domain inherits the same access decision. Teams usually choose this mode for a set of low-sensitivity internal tools owned by one group, where a single sign-in is the main goal. Before you commit, list each application, its owner, the groups that should reach it and whether it needs stricter policies than its neighbors. If any app fails that test, give it its own provider, even if the rest share a domain. Ask your implementation partner or vendor to confirm how cookie domains interact with your DNS layout and how the outpost handles subdomains you add later.
Configuration options and when each one fits
This table compares the two forward auth modes across the settings that shape access control. Read each row as a design choice: the single-application column gives per-app control at the cost of more providers, while the domain-level column trades that control for fewer sign-in prompts across many applications. Confirm each cell against your authentik version before you commit.
| Setting | Single-application mode | Domain-level mode |
|---|---|---|
| Outpost path routing | Routes only /outpost.goauthentik.io on each application's own domain to the outpost | One authentication URL serves many applications under a shared parent domain |
| Number of providers | One proxy provider per application | One shared provider for the whole domain |
| Policy and binding scope | Policies and bindings apply to each application separately | Individual applications cannot carry their own application-level policies |
| Cookie domain | Cookie scoped to the single application's domain | Shared cookie domain covers every protected application under the parent domain |
| Authorization prompts | Users may be asked to authorize each application | Users need not authorize each application separately |
| Applications protected per setup | Suited to one application or a small, separately governed set | Suited to many applications with the same access rule |
| Blast radius of a misconfigured rule | Limited to the one application the rule covers | Can affect every application sharing the domain and cookie |
| Confirm in your version | Exact outpost path, header names and redirect behavior with your reverse proxy | Cookie domain format, logout behavior and how sessions expire across applications |
How per-application policies decide access
In single-application mode, each protected application gets its own proxy provider, its own policy bindings and its own group or policy rules, so access to one application can differ from access to its neighbors on the same parent domain. The outpost evaluates the request against the provider that matches the application's external host, which means a rule such as "members of the finance group only" can sit on the finance dashboard without touching the wiki. Before you commit to this mode, list every application that needs a different audience, and confirm with your authentik administrators how bindings and policy evaluation order will be reviewed and recorded when someone changes them.
Domain-level mode works differently. One authentication URL and a shared cookie domain cover many applications, so a user who has signed in once is not prompted to authorize each one. The trade-off is that the individual applications cannot carry separate application-level policies, so every application under that domain inherits the same access decision. (Illustrative) A finance dashboard and an internal wiki on example.internal would share one gate: a user who can reach the wiki can also reach the dashboard unless the dashboard is protected separately, and a group change applies to both at once.
For this pair, the practical choice is usually to put the finance dashboard in single-application mode, even if the wiki stays on a shared domain setup. Confirm two things in your own environment before deciding: whether any application on the shared domain must enforce a stricter audience than the rest, and whether your reverse proxy can route the outpost path for each host you protect. The authentik forward auth documentation describes both modes and the settings each one requires.
Access control trade-offs to weigh before choosing a mode
Both modes change who gets in, how far one sign-in reaches, and how much configuration your team maintains. The cards below cover the decisions that connect those effects, so you can settle them against your own application inventory before creating any providers.
Broader reach from one session
In domain-level mode, one authenticated session on the shared cookie domain can open every application that uses that outpost. A user who signs in for a low-risk wiki may also reach an internal finance tool on a sibling subdomain if no other control stops them. Before choosing this mode, list which applications share a parent domain and confirm that a single sign-in is an acceptable grant for all of them.
Provider count and upkeep
Single-application mode creates one provider, one application and its bindings for each protected host. That gives precise control but adds objects your team must create, name, review and retire when an application is decommissioned. Estimate the number of hosts you expect to protect over the next year, then decide whether your team can keep that inventory accurate through its normal change process.
Least-privilege reviews
Access reviews are easier when each application has its own policy bindings, because a reviewer can read one application and see who may enter it. Domain-level mode moves that decision into a shared path, so reviewers must trace group membership and any path rules outside the application itself. Decide who will sign off on access for each application and whether they can do that from the authentik admin interface without extra documentation.
Shared cookie scope exposure
The shared cookie is valid for every host under the cookie domain, so its scope is only as safe as the least-protected service on that domain. A compromised or poorly maintained subdomain that can read or set cookies on the parent domain widens the blast radius for every application under it. Inventory the subdomains under the cookie domain, including old test or marketing hosts, and confirm that each one is owned and maintained.
Mixed sensitivity on one domain
Many organizations run public documentation, customer-facing tools and administrative consoles under one parent domain. Putting those together in domain-level mode forces one authentication outcome on applications with very different risk. A practical split is to keep high-sensitivity applications on their own host with a dedicated provider and policies, and reserve the shared mode for applications whose users and controls are alike. Record that split as a rule before rollout.
Removing access across applications
When an employee leaves or a group membership is removed, the effect depends on the mode. With per-application bindings, removing access from one provider does not automatically change others, so your offboarding steps must cover every binding. With a shared session, a user may keep reaching other applications until the session ends, so confirm the session lifetime and test a revocation before relying on it. Ask your vendor or test environment to confirm exactly how revocation behaves in your version.
Setting up single-application forward auth step by step
This sequence produces one authentik proxy provider per application, bound to the outpost and gated by its own policies, so that a single protected host can be tested for allowed and denied access before anything else depends on it.
Confirm the external host and outpost mode
Before touching authentik, the platform owner records the exact external hostname the users will open, such as the application's public name, and confirms that the reverse proxy in front of it can send a single path to a separate service. Decide whether the proxy outpost will run in the embedded outpost or as a standalone outpost, and confirm the outpost's network path from the reverse proxy. Write down the hostname and the outpost location in the change record. The step is done when someone other than the author can read the record and name the host, the proxy and the outpost that will answer for it.
Create the proxy provider for the host
In the authentik admin interface, the administrator creates a proxy provider in forward auth single application mode and sets the external host to the application's exact address. Choose the authorization flow and token validity settings that match your access policy, and confirm the provider type is proxy rather than an OAuth2 or SAML provider. Because this provider serves only one host, it does not share a cookie domain with other applications. The step is done when the provider saves with the external host shown as the single protected address.
Create the application and bind it to the outpost
The administrator creates an application entry that points to the new proxy provider and assigns the provider to the outpost that the reverse proxy calls. Check that the outpost lists the provider in its configuration, which confirms that the outpost knows which host it protects. If the outpost is deployed by a container or Kubernetes integration, confirm that it has picked up the update before continuing. The step is done when the outpost shows the provider as assigned and the application appears in the application list with the expected provider.
Attach policies and group bindings
The administrator binds the application to the groups or policies that decide who may reach it, such as a group for the team that uses the application. Each application carries its own bindings, so a policy change here affects only this host, which is the main reason to choose this mode. Record which groups are bound and what each group is expected to do. The step is done when the bindings are visible on the application and a second person has reviewed the group list against the access request.
Route only the outpost path to authentik
On the reverse proxy, the platform engineer routes the outpost path, which authentik documents as the /outpost.goauthentik.io path, on the application's domain to the outpost, and sends all other paths to the application as usual. The proxy must also pass the outpost's authentication check result and identity headers according to the forward auth documentation for that proxy. Test the configuration syntax with the proxy's own validation command before reloading. The step is done when requests to the outpost path reach authentik and requests to ordinary application paths still reach the application.
Test a denied user and an allowed user
The tester signs in as a user who is not in any bound group and confirms that the application is not reached and that the user is sent to the authentik login flow or receives a denial, depending on the configured flow. Then the tester signs in as a user in a bound group and confirms that the application loads and that identity headers reach it when the application expects them. Keep the test results with the change record. The step is done when the blocked user is denied in a private session, the allowed user reaches the application, and both results are recorded.
Adapt the sequence for domain-level setup
A domain-level deployment follows the same order of work but changes the provider and cookie configuration: one provider covers a parent domain, the cookie domain is set so that a session is shared across the applications under it, and the reverse proxy routes the outpost path on each protected host. Policies are then applied at the level the provider supports, so per-application bindings are not available in the same way. Confirm the cookie domain with the outpost documentation and retest a denied and an allowed user on two hosts. The step is done when a session established on one host is accepted on the second host and the access results match the chosen policy model.
How to test that every application is actually protected
Test each protected host from outside the trust boundary before you call the setup finished. For every hostname that sits behind the outpost, send a request with no session cookie and confirm that authentik redirects to its login flow rather than returning the upstream response. Then sign in as a user who is not a member of the group or bound to the application, and confirm that access is denied at the authorization step, not just hidden in the interface. Run both checks with a plain HTTP client or a private browser window so that a cached session cannot mask a failure. Record the host, the status code, and the final redirect target for each run so the results can be repeated after every change.
Confirm that the application cannot be reached except through the proxy. Even when authentik answers correctly, an application can still be exposed on its own port, through a container network, or through a second ingress route. From a network position that should not reach the application directly, attempt to connect to its upstream address and to any alternative hostname. Then check the proxy configuration itself: the outpost path, the forwarded identity headers, and whether the upstream trusts client-supplied headers. Illustrative example: if a team protects wiki.example.internal but the same service still listens on a published port, the login page is decorative for anyone who finds that port.
Repeat the checks every time a new application joins a domain-level setup. Under shared cookie domain authentication, a new hostname is protected only if the proxy routing for that host sends it through the outpost, so a missed route or an omitted binding can leave an application open without any error appearing in authentik. Add the new host to your test list before go-live, run the unauthenticated and unauthorized checks, and review the bindings on the outpost's provider to confirm that the application is covered. Ask your vendor or your own platform team to confirm how the version you run reports unmatched requests, since the behavior you rely on for detection should be verified in your environment, not assumed.
Limits and what to confirm in your environment
Domain-level forward auth trades per-application control for fewer authorization prompts, and the limits below decide whether that trade works in your network. Verify each one in a test environment against your own DNS, TLS, proxy and upgrade plan before you choose a mode.
Cookie domain behavior
A shared cookie domain only reaches hostnames under the same parent domain, and it depends on how your DNS zones, subdomains and TLS certificates are laid out. Applications on unrelated domains or on separate certificate chains may not receive the session cookie at all. Test a login on each hostname class you plan to protect, including any hostname that sits outside the parent domain, and confirm the cookie is set and sent as expected.
Outpost and supported versions
The outpost and the authentik server should run matching versions, and only certain release lines receive security fixes under the project's security policy. Check which versions are currently supported, confirm the outpost image you deploy matches your server version, and plan how you will apply security releases, which the project announces at least 24 hours in advance.
Reverse proxy outpost path routing
Forward auth only works when your reverse proxy sends the outpost path to authentik before the application receives the request. Confirm the proxy forwards that path to the outpost for every protected hostname, passes the identity and redirect headers in both directions, and does not cache or rewrite them. A missed route usually shows up as a redirect loop or as an application that loads without any login prompt.
PostgreSQL connection capacity
The 2025.10 release notes state that authentik no longer uses Redis and moves caching, tasks, sessions and WebSocket functions to PostgreSQL, and they warn of roughly 50% more PostgreSQL connections after upgrading. Size your connection limits or pooler before upgrading, and watch connection counts during a test rollout. Confirm the figure against your own worker and outpost count.
Enterprise feature requirements
Some controls you may need for domain-level or per-application access sit in the enterprise edition, such as mTLS client certificate authentication, enhanced audit logging and password history. Review the pricing page against your access control requirements before you pick a mode, and ask the vendor in writing which features are covered by your license and which edition your use case needs. The enterprise license also applies to code in a separate directory of the repository.
Questions teams ask before choosing forward auth mode
Is one domain-level forward auth provider enough for all our internal apps?
Often it is enough for applications that share one parent domain and need the same access rule for every signed-in user. Domain-level forward auth uses one authentication URL and a shared cookie domain, so users authorize once and move between applications without repeated prompts. The trade-off is that individual applications cannot carry their own application-level policies. If finance, HR and a wiki share one rule set, one provider may be enough. If any app needs group-specific access, plan for per-application providers from the start. Confirm the rule set for each app with the owners before you decide.
What drives the effort of moving from domain-level to per-application mode?
The main driver is how many applications change and how many distinct access rules they need. Each application that moves to per-application mode needs its own provider, its own policy bindings and its own proxy route, and the outpost must route the outpost path on that application's domain. Effort rises with the number of applications, the number of policies per application and the number of reverse proxy configurations that must change. Cookie domain changes and user sessions also need testing, because users may be re-prompted. Ask for a list of applications, their current rules and their proxy setup before estimating.
What does the work need from our own team?
Your team needs to supply application owners, the list of users and groups that should reach each app, the reverse proxy configuration and access to the hosts or clusters where authentik and its outposts run. Someone must decide who approves policy changes and who owns the cookie domain, since those choices affect every application on it. Plan time for these people to review test results. Work that depends on decisions from your side usually takes longer than the configuration itself, so agree on owners before the scope is signed.
Can our own staff configure forward auth without outside help?
Staff who already run a reverse proxy and understand OIDC sessions can usually configure a single application as a pilot, using the authentik documentation for the proxy provider. Domain-level setups are simpler to start, but policy design and cookie domain decisions are where mistakes appear. Ask whether your team has someone who can own authentik upgrades, since the project supports only specific security release lines, and whether that person can test changes in a non-production environment first. A partner can take on the design and build while your team keeps operational ownership.
How long does a pilot take to validate the chosen mode?
A useful pilot covers one application in each mode, with a real reverse proxy route, a test user from each group and a check of login, logout, session expiry and redirect behavior. The duration depends on how many proxy paths you test, how many identity groups are involved and how quickly your change process approves configuration. No duration is set by the authentik documentation for this, so agree the pilot exit criteria in writing and confirm the timeline in the statement of work before work starts.
What affects the cost of this work the most?
Cost depends on the scope agreed in writing, which normally covers the number of applications, the policy complexity for each one, the number of proxy platforms involved and whether the outpost runs on Docker or Kubernetes. Licensing is a separate line: authentik's pricing page lists an Open Source edition at no cost and an Enterprise edition priced per user, so confirm which edition you need before comparing quotes. Ask each bidder to price one-time build work and recurring support separately, and to state which applications and environments are included.
Do the forward auth modes change how we handle access reviews?
Yes. Per-application providers give you one place to read who can reach each application, which simplifies access reviews and audit evidence. Domain-level setups put many applications behind one rule, so reviews must check the shared rule and any exceptions handled elsewhere. Record the chosen mode, its owners and the review cadence in your access control documentation. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, so confirm evidence expectations with your independent auditor.
How DeployOpen scopes and delivers forward auth design
DeployOpen plans and implements authentik inside your own infrastructure, so the choice between one provider per application and one provider for a parent domain is made against your applications, your domains and your access model. The work is documented and handed over so your team can run the result.
How we scope
- Inventory every application behind the proxy, its domain, its owner and the groups that should reach it.
- Record which applications need their own policies, MFA steps or authorization prompts, and which can share one domain-level setup.
- Agree the written scope, deliverables and timeline in writing before work starts, since most engagements are fixed-scope.
How we build
- Configure the proxy providers, outpost routing and cookie domain for the chosen mode, and document each application's binding.
- Test login, logout, redirects and header passing for each protected application, including requests made without a session.
- Verify that a user without the right group or policy is refused on every path, not only on the main login page.
How we hand over
- Deliver a written record of the chosen mode, the reasons for it, the provider list and the policy bindings per application.
- Walk your operations and security teams through adding a new application to the setup, step by step, with the rollback path.
- Document the known limits of the chosen mode, including what domain-level sharing means for per-application access control.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retest protected applications after authentik upgrades or reverse proxy changes, since outpost and cookie behavior can shift.
- Ask any support partner to confirm response terms, the version support window and the upgrade path in the written agreement.
