Introduction

Traefik forward authentication lets you delegate access control to a separate service before a request reaches your application. In Kubernetes, that is useful when you want central authentication for many services without embedding the same login or token logic into every app.

How Forward Authentication Works

With forward auth enabled, Traefik receives the incoming request and sends a subrequest to an authentication service. That service decides whether the request should continue.

The contract is simple:

• if the auth service returns 2xx, Traefik forwards the request to the backend
• if the auth service returns 401 or 403, Traefik stops and returns that result to the client
• optional headers from the auth response can be copied to the backend request

This makes the auth service a policy decision point. It can validate cookies, JWTs, OAuth sessions, API keys, or headers from an identity-aware proxy.

Traefik v2 Configuration Pattern

In Traefik v2 on Kubernetes, forward auth is commonly configured through a Middleware resource and then attached to an IngressRoute or standard Ingress.

A minimal middleware looks like this:

1apiVersion: traefik.io/v1alpha1
2kind: Middleware
3metadata:
4  name: authn
5  namespace: apps
6spec:
7  forwardAuth:
8    address: http://auth-service.apps.svc.cluster.local/verify
9    trustForwardHeader: true
10    authResponseHeaders:
11      - X-User
12      - X-Email

Then attach it to an IngressRoute:

1apiVersion: traefik.io/v1alpha1
2kind: IngressRoute
3metadata:
4  name: app-route
5  namespace: apps
6spec:
7  entryPoints:
8    - websecure
9  routes:
10    - match: Host(`app.example.com`)
11      kind: Rule
12      middlewares:
13        - name: authn
14      services:
15        - name: app-service
16          port: 80

In this setup, every request to app.example.com is first sent to auth-service for verification.

What the Auth Service Must Do

The auth service does not need to proxy the whole request body back to Traefik. It only needs to inspect the request and return the right status code and headers. A tiny Python example makes the idea concrete:

1from flask import Flask, request, Response
2
3app = Flask(__name__)
4
5
6@app.get("/verify")
7def verify():
8    token = request.headers.get("Authorization", "")
9    if token == "Bearer secret-token":
10        response = Response(status=200)
11        response.headers["X-User"] = "demo-user"
12        response.headers["X-Email"] = "[email protected]"
13        return response
14    return Response("unauthorized", status=401)
15
16
17if __name__ == "__main__":
18    app.run(host="0.0.0.0", port=8080)

If the token is valid, Traefik forwards the request and can pass X-User and X-Email through to the backend.

Choosing Between Forward Auth and App-Level Auth

Forward auth is a good fit when multiple services need the same access policy. It centralizes login checks, lets you reuse SSO integrations, and keeps backend services simpler.

It is not always the whole answer, though. Your application may still need authorization rules after authentication succeeds. Forward auth can prove who the caller is, but the app may still need to decide what that user is allowed to do.

Common Pitfalls

The most common mistake is pointing Traefik at an auth endpoint that returns redirects or HTML login pages when Traefik expects a clean allow or deny response. The auth service should behave like an API, not like a browser-only frontend.

Another common issue is forgetting to propagate identity headers. If the backend depends on X-User but the middleware does not list it under authResponseHeaders, the backend never sees it.

It is also easy to misread trustForwardHeader. Enable it only when you trust the upstream headers that Traefik receives. In the wrong environment, that can let spoofed identity information through.

Summary

• Traefik forward auth delegates request validation to a separate service.
• A 2xx response allows the request, while 401 or 403 blocks it.
• In Kubernetes, the usual pattern is a Middleware attached to an IngressRoute or Ingress.
• The auth service should return clean status codes and any identity headers the backend needs.
• Forward auth centralizes authentication, but application-level authorization may still be required.