Authentik reverse proxy setup and custom authentication flows

Choose the forward-auth boundary

• Single application. Protects one application host and allows separate provider, policy, binding, and authorization behavior for that application.
• Domain level. Protects multiple applications under a shared parent domain with one provider and session, but cannot enforce different application-level policies for each protected application.
• Design implication. Use domain-level mode only when the protected applications genuinely share an access policy. Convenience should not erase an authorization boundary.

Traefik forward-auth example

Point Traefik's forward-auth middleware at the authentik outpost and return only the identity headers the upstream application actually needs. Keep the outpost on a trusted network path and validate which proxy headers authentik accepts.

http:
  middlewares:
    authentik:
      forwardAuth:
        address: "http://authentik-server:9000/outpost.goauthentik.io/auth/traefik"
        trustForwardHeader: true
        authResponseHeaders:
          - X-authentik-username
          - X-authentik-groups
          - X-authentik-email

  routers:
    internal-app:
      rule: "Host(`app.internal.example.com`)"
      middlewares:
        - authentik

Common failure modes

• Missing outpost route. The protected host must route /outpost.goauthentik.io to the outpost as shown in the official template. A missing callback route commonly produces a successful login followed by a redirect loop.
• Wrong proxy trust. Accept forwarded headers only from known proxy networks. Untrusted clients must not be able to supply identity or original-request headers.
• Rule and middleware order. Confirm router priority and middleware order so callback requests reach the outpost and every protected route receives the intended authentication check.
• Overbroad response headers. Forward the minimum required identity data. Treat JWTs and group claims as sensitive and make the upstream application validate the trust boundary.
• Cookie scope. For domain-level mode, set the cookie domain to the intended parent domain and avoid broadening it beyond the applications that share the policy.

Customize flows safely

Authentik flows contain ordered stages, and policies decide whether a flow, stage, application, or source is allowed to run. Policies on stage bindings are evaluated dynamically by default, immediately before the stage.

For passkeys, prefer the built-in WebAuthn setup and validation stages and the Identification stage's passkey support. If a custom expression is still necessary, use the documented pending-user and flow context, test anonymous and recovery paths, and treat edit access as privileged code execution.

• Clone or export the active flow before changing it, then store the reviewed Blueprint in version control.
• Test users with and without passkeys, failed WebAuthn, recovery, enrollment, disabled accounts, and administrative emergency access.
• Confirm whether each policy is evaluated dynamically or when the flow is planned; early evaluation may occur before a pending user is known.
• Stage changes outside production and retain a recovery key or documented rollback path before replacing the active authentication flow.

Primary references

• Authentik documents mode behavior and authorization limits in Forward auth.
• Authentik explains flow sequencing and evaluation in Flows.
• Authentik documents server-side Python risks and context in Expression policies.
• Authentik documents the supported passkey path in Identification stage.

Related resources

• Compare Authentik's configuration model with Keycloak in Keycloak vs. Authentik for GitOps and multi-tenancy.
• Plan long-term ownership with Open-source identity and SSO: the real cost of self-hosting.