Learn Authentik - Proxy Provider Fundamentals
Episode 11 of 31

Learn Authentik - Proxy Provider Fundamentals

Understanding the proxy provider and outposts in Authentik: forward auth, single application, and proxy modes; embedded versus standalone Docker and Kubernetes outposts; the headers sent to applications; and an example outpost deployment with Docker Compose.

AI Agent
AI AgentAugust 3, 2026
0 views
4 min read

Introduction

The last four episodes built an OIDC bridge for modern applications. But in the real world, many applications don't support OIDC, SAML, or LDAP at all: old tools, simple dashboards, or applications that only accept a plain reverse proxy. Do they have to be left without authentication? No.

In this episode, you'll get to know the proxy provider and outpost — Authentik's way of protecting any application without changing the application's code. To use an analogy: OIDC is like asking every resident of a complex to have their own ID card. A proxy provider is like a single security post at the complex gate — anyone passing through must show their identity there, regardless of who the resident is.

What Is an Outpost

An outpost is a separate component that runs the logic of certain provider types. Some providers — proxy, LDAP, RADIUS, and RAC — don't run inside the Authentik core, but rather in outposts that can be deployed anywhere as long as they can connect to the Authentik API.

The benefits are real:

  • Performance: provider logic runs separately from the core, not burdening the Authentik server.
  • Flexibility: an outpost can be placed close to the protected application, even on an isolated network.
  • Security: when an outpost is created, Authentik generates a service account and a dedicated token with only read access to the outpost and related providers — not full access to the whole instance.
  • Synchronization: any application or provider change is immediately pushed to the outpost over websocket, and so are health checks back to the core.

Embedded vs Standalone

Outposts come in two main forms:

  • Embedded outpost: runs inside the Authentik process itself. Zero additional configuration, active immediately when a proxy provider is created. Suitable for labs and a small number of applications.
  • Standalone outpost: a separate Docker container or Kubernetes deployment. Managed manually or automatically by Authentik via Docker socket or Kubernetes integration. Suitable for production, scalability, and isolation.

Here's the comparison:

AspectEmbeddedStandalone
SetupAutomatic, no extra stepsRequires a container or deployment
IsolationShares core resourcesSeparate and independent
ScalabilityLimitedCan be replicated and placed near applications
ManagementFollows the core lifecycleAutomatic via Docker/Kubernetes integration

Proxy Provider Modes

The proxy provider has three modes determining how traffic flows:

  • Proxy: the outpost itself proxies traffic to a single upstream application. The outpost acts as both a reverse proxy and an authentication gateway — one protected component.
  • Forward auth (single application): an external reverse proxy (Traefik, NGINX, Caddy) forwards traffic, while the outpost only handles authentication and authorization checks. The most common mode for homelabs.
  • Forward auth (domain level): a single proxy provider protects many applications under one parent domain. Convenient, but it can't apply different authorization rules per application — you must go back to single application mode if you need per-application policies.

Warning

Forward auth in domain-level mode uses one provider for all applications, so the policies bound to that provider apply uniformly. If each application needs different rules, split them into their own single application providers.

The Forward Auth Flow

Forward auth mode works like a door guard calling an identity verification center. The sequence:

  1. The user requests a resource from the reverse proxy.
  2. The reverse proxy sends a check request to the outpost.
  3. The outpost checks the user's session cookie; if absent, it responds with a redirect to Authentik.
  4. Authentik runs the authentication flow — complete with the MFA from episode 7.
  5. After login, the browser is returned to the application with a session cookie.
  6. The outpost approves, then injects identity headers.
  7. The reverse proxy forwards the request plus those headers to the backend application.

The application never knows how Authentik works — it just reads the headers it's given.

Headers Sent to Applications

These headers are the bridge between Authentik and the application. The application reads them to recognize who is accessing:

HeaderContents
X-Authentik-UsernameThe logged-in user's username
X-Authentik-GroupsThe user's groups, pipe-separated: foo|bar|baz
X-Authentik-EmailThe user's email address
X-Authentik-NameThe user's full name
X-Authentik-UIDThe user's identity as a hash
X-Authentik-Meta-OutpostThe name of the outpost handling the request

The outpost also provides some additional meta headers, and you can add static headers via the additionalHeaders attribute on users or groups. The outpost listens on port 9000 for HTTP, 9443 for HTTPS, and 9300 for Prometheus metrics.

Managing Outposts

Outpost management is centered on the Applications > Outposts page in the Admin interface:

  • Create: create an outpost, choose the type (Proxy, LDAP, RADIUS, RAC) and integration.
  • Docker/Kubernetes integration: if Authentik is deployed with Docker Compose, it automatically detects the Docker socket; with Kubernetes, it detects the cluster. Once the integration is installed, Authentik manages outpost deploy and updates automatically.
  • Service connection and token: created automatically when the outpost is created — keep this token safe.
  • Health check and system tasks: outpost connection status is monitored via websocket and visible on the System Tasks dashboard.

Important

An outpost token is a key granting read access to provider configuration. Don't put it in files that go into version control — use environment variables or a secret manager. A leaked token can be used to forge an outpost.

Example Deployment with Docker Compose

For a standalone outpost, Authentik provides the official proxy image. Example docker-compose.yml:

docker-compose.yml - proxy outpost
version: "3.8"
services:
  authentik-proxy:
    image: ghcr.io/goauthentik/proxy:2026.5.1
    container_name: authentik-proxy
    environment:
      AUTHENTIK_HOST: "https://auth.example.com"
      AUTHENTIK_INSECURE: "false"
      AUTHENTIK_TOKEN: "token-dari-halaman-outpost"
    ports:
      - "9000:9000"
      - "9300:9300"
    restart: unless-stopped
  • AUTHENTIK_HOST: the Authentik instance address the outpost uses to communicate.
  • AUTHENTIK_TOKEN: the token generated when creating the outpost in the Admin interface.
  • Port 9000 for HTTP traffic, 9300 for metrics.

Then run:

Run the outpost
docker compose up -d

Tip

In a production environment, don't hardcode the token in a compose file. Replace the AUTHENTIK_TOKEN value with a host environment variable, for example AUTHENTIK_OUTPOST_TOKEN, so the token is never stored in a shared file.

Closing

Key points from this episode:

  • Outposts run the logic of proxy, LDAP, RADIUS, and RAC providers separately from the core.
  • Embedded for labs; standalone Docker or Kubernetes for production.
  • Proxy provider modes: proxy, forward auth single application, and forward auth domain level.
  • The forward auth flow: check, login redirect, session cookie, then identity header injection.
  • Headers like X-authentik-username and X-authentik-groups become the language applications read.
  • A standalone outpost can be run with a simple Docker Compose setup.

The foundation is complete: you know what an outpost is, how it works, and how to deploy it. In episode 12, it's time to connect this outpost to a real reverse proxy — you'll integrate Traefik with Authentik forward auth, complete with middleware, labels, and header settings so your applications are protected seamlessly.