How authentik fits as an Envoy or Istio external authorization service
If your traffic already flows through an Envoy-based proxy or an Istio mesh, you may want authentik to make the access decision on each request rather than adding a second gateway in front of your services. The external authorization pattern works this way: the data plane pauses a request, sends its headers and path to an external service, and forwards the request only if that service allows it. In this model, the proxy or sidecar enforces the decision and the authorization service makes it. That differs from the forward auth setup covered elsewhere on this page, where a reverse proxy calls the authentik outpost on a dedicated path and the outpost answers with redirects or identity headers. External authorization fits best when a mesh already controls east-west and north-south traffic and you want one policy point across many services, not one per ingress.
The researched facts for this page do not document an Envoy or Istio external authorization integration for authentik. The authentik provider list covers OAuth2/OIDC, SAML, LDAP, proxy, RADIUS, SCIM and other types, and the proxy outpost is the component that performs per-application checks, but no supplied source describes it speaking the Envoy ext_authz gRPC or HTTP protocol or exposing the endpoints a mesh would call. Before you design around this pattern, confirm with the authentik documentation for the release you run whether an ext_authz-compatible endpoint exists, which protocol and port it uses, what request paths it expects, and which headers it returns. Ask the same question of your Istio or Envoy version, because the mesh configuration depends on it.
Until that is confirmed, treat the pattern as an open design question with a fallback. Decide which paths must reach authentik and which can bypass it, how per-application policies will map to mesh routes, and how sessions and redirects to the login flow will behave for browser traffic and API clients. If the integration cannot be verified in your release, a supported forward auth setup at the edge, or a mesh-native policy layer that does not depend on authentik, may be the safer option. Plan a proof of concept in a non-production namespace to test redirects, token handling and failure behavior before any production route depends on it.
Envoy ext_authz or Istio mesh policy: which path fits your cluster
In a standalone Envoy deployment, the check runs in the Envoy listener or gateway that terminates traffic for one or more applications. Envoy's HTTP filter for external authorization sends each request, or a configured subset of requests, to the authentik outpost acting as the ext_authz service. Envoy then allows or denies the request and can copy selected response headers, such as the identity headers authentik returns, onto the upstream request. The platform or networking team usually owns the Envoy configuration, while the identity team owns the authentik provider, application and policy objects.
- Enforcement point: the gateway listener or route, so requests that bypass it are not checked unless the application is also unreachable directly.
- Configuration owner: the platform team edits Envoy resources, and changes to route matching need review by the application owners.
- Path scope: decide which paths go to authentik and which, such as health checks or static assets, are excluded from the check.
- Header contract: agree which identity headers the upstream application trusts and confirm that Envoy strips client-supplied copies of them.
- Coordination: the identity team must confirm the outpost endpoint, the public login hostname and the cookie domain before routes change.
Before go-live, confirm that the outpost is reachable from the Envoy pod or host and that a request to a protected path redirects to login as expected.
In an Istio mesh, external authorization is defined once in mesh configuration as a named provider that points to an authorization service, and then applied to workloads or gateways with authorization policies that use the custom action. The enforcement happens in the sidecar or waypoint proxy of the workload being protected, so checks follow the workload rather than a single entry point. This model suits clusters where many services need the same authentication rule, but it spreads the decision across many workloads and namespaces.
- Provider definition: the mesh administrators register the authentik outpost as an extension provider in the mesh configuration, and that definition is cluster-wide.
- Policy scope: authorization policies select workloads by label and namespace, so a broad selector can apply the check to services that were never meant to be gated.
- Configuration owner: the platform or mesh team owns the provider and the policies, while application teams may need to request exceptions.
- Identity coordination: the identity team must confirm the outpost is reachable from every namespace that enforces the policy, and that per-application policies in authentik match the workloads selected in the mesh.
- Failure behavior: confirm how the mesh treats requests when the authorization service is unavailable, since that choice decides between an outage and an unchecked request.
Before go-live, test one non-production workload with a deny and an allow case and confirm which Istio version and provider settings your own environment uses.
Many estates run an edge gateway for external users and a mesh for internal service-to-service traffic. Both can call the same authentik outpost, but each layer checks different requests, and a request from outside may be checked twice, once at the gateway and again at a mesh workload. The design question is which layer is the authoritative check for each application, and how the two layers avoid conflicting redirects, cookies and header rules.
- Authoritative layer: decide per application whether the gateway or the mesh makes the final decision, and document it.
- Double checks: a second check adds latency and can cause redirect loops if both layers issue login redirects for the same request.
- Ownership split: the platform team typically owns the edge gateway, the mesh team owns workload policies, and the identity team owns authentik objects, so one change can touch three owners.
- Header trust: internal workloads must not accept identity headers from callers that bypass the gateway, which means the mesh should verify the request path rather than trust headers alone.
- Change control: a single change request should list which layer changes, which application policy changes and who approves each.
Before go-live, trace one login from the outside and one internal call through both layers to confirm each request is checked exactly as the design states.
Which requests to send to authentik and how to scope policies
This table compares the configuration decisions that shape an authentik external authorization setup in Envoy or Istio: which paths are checked, which bypass the check, how policies are scoped and where checks run. Read each row against your own application inventory, and confirm the exact mechanics for your authentik version and mesh before you commit to a pattern.
| Decision | When it fits | Trade-off in access control and operations |
|---|---|---|
| Check every route through the outpost | Applications with no public paths and a single sign-in experience for all users | Strongest default for access control, but every failure of the outpost blocks all traffic on the route, so outpost capacity and health checks become critical |
| Bypass health checks and readiness probes | Kubernetes probes and load balancer checks that cannot carry a session | Keeps the platform running during an authentik outage, but these paths must return nothing sensitive, so keep them narrow and list them explicitly |
| Bypass public assets and static files | Stylesheets, images and scripts needed on the login page or public site | Reduces outpost load and avoids redirect loops, but every bypassed prefix is a path you must review for data exposure |
| Bypass login and callback endpoints | Sign-in, OIDC callback and logout paths that the outpost must reach without a session | Required to avoid loops, yet misconfigured bypasses can expose application routes that share the prefix, so match exact paths where possible |
| Per-application policies in authentik | Separate applications with different groups, MFA rules or risk conditions | Gives the clearest audit trail per application, but each application adds provider and policy objects that someone must maintain and test |
| Shared policy across several applications | Applications that share one audience, such as all internal tools for one department | Less administration, but one policy change affects every application in the group, so changes need review and a rollback plan |
| Identity headers returned upstream | Backends that read user, email or group headers instead of validating tokens | Simple for legacy apps, but backends must accept headers only from the gateway, or a client can forge them. Confirm which headers the outpost returns for your version |
| Checks at the gateway | A single ingress point where one policy path covers many services | Central control and fewer moving parts, but the gateway becomes a shared dependency and misrouted paths can skip checks |
| Checks per workload or sidecar | Service-to-service isolation or mesh policies that vary by workload | Finer control per service, but more configuration to keep consistent and more places where a check can be missed |
Setting up the external authorization check in the right order
This sequence takes you from a confirmed authentik release to a tested ext_authz path in Envoy or an Istio mesh, with each step gated by a check so enforcement only widens after the outpost is proven. It produces a tested allow, deny and bypass matrix for the applications in scope.
Confirm the authentik release and supported lines
Before installing anything, check the latest release on the authentik releases page and the supported version lines in the security policy. The release page lists 2026.8.4 as the latest, published October 14, 2026, and the security policy lists 2026.5.x and 2026.8.x as receiving security fixes. Record which line you will deploy, subscribe to the security announcements, and confirm with your team that the chosen line matches your upgrade plan. Done when the target version and its support status are written into the change record.
Deploy the authentik server, worker and PostgreSQL
Install authentik with its server container (core plus an embedded outpost), its worker container for background tasks, and PostgreSQL, which holds all configuration and data except uploaded files. For a Docker Compose host, the authentik guide calls for at least 2 CPU cores and 2 GB of RAM and positions Compose for test and small-scale production. For Kubernetes, install with the Helm chart, but the bundled PostgreSQL is intended for demonstration and testing, so run a separately managed PostgreSQL for production. Confirm the admin login works, the worker is processing tasks, and the database connection is healthy before moving on.
Configure the outpost and providers for each application
Create a proxy provider for each application that will be checked, and bind it to an application and an outpost in authentik. Decide per application whether the provider covers a single host or a parent domain, since that choice sets cookie scope and the policies you attach. Attach policies and group bindings to each application so that access decisions are made per application rather than globally. Confirm the outpost reports healthy in the authentik admin interface and that a test user receives the expected result for one application through the outpost's own endpoint.
Register the ext_authz endpoint in Envoy or the mesh
Point Envoy's ext_authz filter, or the Istio external authorization provider defined in mesh configuration, at the authentik outpost endpoint and choose whether requests are sent as HTTP or gRPC according to the outpost's supported interface for your version. Set the timeout and failure mode deliberately, since a fail-closed setting denies traffic when authentik is unreachable. Keep the filter disabled or scoped to a test namespace at this stage. Done when the configuration validates and the proxy reports the cluster as reachable with the authorization service healthy.
Route only the intended paths through the check
Scope the check to the paths and hosts you intend to protect, using per-route or per-workload settings in Envoy or authorization policies in Istio. Leave the authentik login, callback and outpost paths outside the check so that users can actually sign in, and exclude health endpoints that load balancers poll. Write the path list into the change record and review it with the application owners. Done when a request to a protected path is sent to the check and a request to an excluded path is not.
Test allow, deny and bypass cases
Run a written test matrix before widening enforcement. Cover an authorized user who should receive access, an unauthorized user who should be denied, an unauthenticated request that should redirect or be refused, and a direct request to the application's service that should not bypass the mesh or proxy. Also test that the excluded paths behave as designed and that a stopped outpost produces the failure mode you chose. Record each result with the request, identity and response. Only after every case passes should you enable enforcement for additional namespaces or applications.
Widen enforcement and keep the matrix current
Expand the check to further applications one group at a time, repeating the path and test steps for each. Keep the test matrix in version control and rerun it after each authentik upgrade, mesh change or policy change, because policy and routing defects often appear after configuration changes rather than at first install. Confirm with your security team which bypass tests they want retained as recurring evidence. Done when the matrix passes on the production configuration and the owners have signed off the protected path list.
Security controls around the external authorization path
An external authorization check is only as strong as the path around it. The controls below cover what happens when authentik cannot answer, which identity headers the mesh trusts, who can reach the outpost directly, and how the outpost token and the authentik release line are kept current.
Fail closed when authorization is unreachable
If the ext_authz service cannot be reached or times out, the proxy must deny the request rather than pass it through. Whether a given Envoy or Istio setup fails open or closed depends on the failure mode settings you configure, so do not assume a default. Test it by stopping the outpost in a non-production cluster and confirming that protected routes return an error, not the application.
Limit forwarded and trusted headers
Identity headers set by authentik are only trustworthy if the mesh strips any copies sent by the client and forwards only an approved list to the upstream. Decide which headers the application reads, list them explicitly in the external authorization configuration, and confirm that a request carrying a forged user header is rejected or cleaned before it reaches the app.
Block direct access to the outpost
The outpost endpoint should accept checks only from the proxy that calls it. If it is reachable from other workloads or from outside the cluster, an attacker can probe it or send crafted requests. Restrict network policy or service exposure to the mesh components, and verify from an unrelated pod that the endpoint cannot be reached.
Scope RBAC for mesh and policy objects
Whoever can edit authorization policy, external provider definitions or mesh configuration can change which requests reach authentik and which skip it. Grant write access to these objects to a small group, separate it from application deployment rights, and review changes through the same workflow as other production configuration.
Handle outpost tokens as secrets
The outpost token lets a component act on behalf of the authentik outpost. Store it in a Kubernetes Secret or external secret store, not in manifests or values files in Git, restrict who can read that Secret, and rotate the token when staff with access leave or when you suspect exposure. Confirm the rotation steps with authentik's current documentation.
Stay on a supported authentik release
The authentik security policy lists the release lines that receive security fixes, and the project announces security releases at least 24 hours in advance. Track the supported lines, schedule upgrades so the outpost and server stay on the same supported version, and subscribe to release notices so you have time to plan a patch window.
Choosing which paths reach authentik and where policy lives
The first decision is whether external authorization runs mesh-wide with a bypass list, or narrowly on named hosts and routes. A mesh-wide check with a broad bypass list is simpler to switch on, but every exempted path becomes a permanent hole that someone must review each time a new service appears. Narrow checks, applied per host or per route, make the protected surface visible in configuration, at the cost of more policy objects to maintain. Whichever you choose, list every path that must stay reachable without a decision from authentik: the login pages, the OIDC callback, the token and discovery endpoints, static assets the sign-in page loads, health probes and any webhook callers. Confirm the exact paths against the outpost and provider documentation for your authentik version, since these depend on the provider configuration you chose.
Map authentik's per-application policy to one application and one provider per protected hostname wherever you can. Each application then carries its own bindings, groups and authorization rules, and a change to one service does not alter another. Be deliberate about the login and callback paths: they should not depend on the very check they serve. If the check on the callback route requires a session that only the callback can create, sign-in loops or fails silently. Keep those paths out of the external authorization scope, and test that an unauthenticated request to the protected application is redirected to sign-in while the sign-in and callback paths load without a decision. Record which routes are excluded and why, so the exclusion list stays auditable.
External authorization returns allow or deny decisions to the proxy. It does not render a login page, so redirects, cookies and headers are handled by the data plane and the application, and you must verify them directly. Check that the redirect target built for an unauthenticated request points at the correct authentik host and that the return URL survives the round trip. Confirm the cookie domain and attributes are scoped so the session is sent to each protected host that needs it, and that a session cookie set during login is not stripped by the gateway. Verify the identity headers forwarded upstream are the ones your application expects, and that clients cannot spoof them. Run these checks on every protected route, not one sample, and repeat them after each authentik upgrade, because the supported versions and outpost behavior change between releases.
What to confirm in authentik and your mesh before building
External authorization ties authentik to your proxy layer, your identity model and your cluster lifecycle at the same time. The cards below list the points to verify in each area before you commit to a design, since a mismatch in any one of them can force a rebuild.
ext_authz protocol compatibility
Confirm that the authentik outpost you plan to run exposes the external authorization interface your Envoy or Istio version expects, including the request path, the check method and the response headers the mesh reads. Test this against the exact proxy version in your mesh, not the version in a blog example. If the outpost does not match, the mesh will fail closed or open depending on configuration, so verify the failure mode too.
Provider type and outpost mode
Decide which authentik provider type backs each protected application and whether the outpost runs in a mode that suits per-application or domain-level checks. The provider choice determines which policies apply, which cookies or tokens are issued and how the mesh receives identity. Write the mapping from each route to a provider and outpost before deployment.
Workload identity and mTLS needs
Determine whether service-to-service calls need certificate-based identity. mTLS client certificate authentication is listed on the authentik pricing page as an Enterprise feature, so confirm whether your edition covers it before designing workload identity around it. Mesh mTLS between sidecars is a separate control, and the two should not be assumed to be the same thing.
Supported authentik versions
Check the authentik security policy for the versions currently receiving security fixes and pin your deployment to one of them. Security releases are announced at least 24 hours in advance, so your change process must be able to act on short notice. Record the target version in your mesh runbook so that outpost and server versions stay aligned.
PostgreSQL connection sizing
The 2025.10 release notes say authentik no longer uses Redis and moved caching, tasks, sessions and WebSocket functions to PostgreSQL, with roughly 50% more PostgreSQL connections after upgrading. Size connection limits and any pooler before go-live, especially when every mesh check hits the outpost. Ask your database team how the connection count scales with outpost replicas.
Kubernetes version and skew limits
Mesh upgrades depend on the cluster version. Confirm which Kubernetes minor versions your mesh and authentik outposts support, and follow the skew rule that kube-apiserver is upgraded one minor version at a time, ahead of controllers, scheduler and kubelets. Kubelets may be up to three minor versions older than the API server, so plan node upgrades within that window alongside any Envoy or Istio upgrade.
Questions teams ask before building ext_authz with authentik
What does an Envoy or Istio ext_authz integration with authentik cost?
No DeployOpen price is published, and a quote follows from the written scope. The cost is driven by how many clusters, gateways and mesh policies are involved, how many applications need per-application rules, and how many identity sources and claims must be mapped. The one-time work covers architecture, the outpost deployment, mesh and gateway configuration, policy design and testing. Recurring costs come from keeping authentik and the mesh on supported versions, running the outpost and PostgreSQL, and retaining support if you want it. Ask any quote to separate build work, testing and ongoing support so you can compare it with your own team's effort.
How long does a first ext_authz integration take?
The timeline depends mainly on the number of applications behind the mesh, how much of the routing and policy logic is already documented, and how quickly mesh owners and identity owners can review designs. A single cluster with a small number of protected services is a much smaller job than a multi-cluster mesh with many domains and exceptions. Testing is often the longest phase, because you need to prove that allowed paths pass, denied paths fail, and health and callback routes remain reachable. Agree on the timeline in the written scope, with milestones tied to a test environment and a cutover plan.
What must our team provide before the work starts?
Plan to provide cluster access in the environments you want changed, the names of the mesh or gateway owners who approve changes to Envoy or Istio configuration, and an inventory of the applications that will sit behind the check. Identity owners need to confirm which authentik providers and groups apply, and security owners should state which paths must stay public, such as health checks, login callbacks and metrics endpoints. Also ask for a test account set, change windows and a point of contact for rollback decisions. Missing inventory is the most common reason for rework, so it is worth collecting before design starts.
Can our platform team build this integration without a partner?
Yes, if your team already runs Envoy or Istio, operates authentik, and has the skills to read the mesh and identity configuration. Most of the difficulty is not the single ext_authz rule. It is deciding which paths go to authentik, handling redirects and session cookies correctly, passing identity headers to upstream services, and making sure policy changes do not lock out operators. A partner is most useful when those decisions cut across several platform owners or when the team needs an outside review and test plan. Whichever route you choose, the design and verification steps should be written down before any production change.
Does the open-source edition of authentik support this use case?
The authentik repository is licensed under MIT for most of its code, while the authentik/enterprise/ directory falls under a separate enterprise license. The pricing page lists an Open Source edition at no cost, with community support through Discord. It also lists enterprise-only features such as mTLS client certificate authentication, which may matter if your mesh uses certificates for identity. Confirm in your own environment that the proxy outpost and the authorization features you need are available in the edition you plan to run, and check the license terms with your legal team before you deploy.
What ongoing work follows after an ext_authz integration goes live?
Ongoing work includes upgrading authentik and the outpost in sequence, tracking supported versions on the security policy page, and retesting the mesh after each Envoy or Istio upgrade. New applications need path rules and policies, and removed applications need their rules retired so stale exceptions do not remain. Operations should monitor outpost health, authentication failures and PostgreSQL connections, and keep runbooks for lockouts. Recurring costs therefore come from staff time or a retainer, not only from infrastructure. Ask any proposal to state who owns each recurring task after handover.
How DeployOpen scopes and delivers authentik authorization integrations
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For authentik with Envoy or Istio external authorization, we start from the request paths, the mesh or gateway topology and the per-application policies you need, then build and verify the integration in your environment before handover.
How we scope
- Written scope lists which Envoy or Istio entry points call the authentik outpost as the ext_authz service.
- We map each application route to its authentik provider, policy and required headers before any build begins.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy the authentik outpost and wire the ext_authz configuration in the gateway or mesh you operate.
- We set path exclusions for login, callback and static assets so authentik only checks protected traffic.
- We test allow and deny behavior per application, including expired sessions, redirects and identity headers passed upstream.
How we hand over
- You receive configuration, policy mappings and runbooks covering each gateway route and its authentik application.
- We document the verification steps your team can repeat after changes to routes, policies or mesh versions.
- Handover covers the outpost, the embedded outpost decision and the checks to run after authentik upgrades.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover Envoy or Istio version changes and authentik release upgrades that affect the ext_authz path.
- Ask any provider to confirm supported versions and release notes for your exact gateway and authentik versions before scoping.
