Authentik mit Docker Compose als SSO einrichten

Ein Login für jede gehostete Anwendung

Authentik ist ein selbst gehosteter SSO-Server (Single Sign-on): Ihre Benutzer melden sich einmal an, und jede dahinterliegende Anwendung akzeptiert diese Sitzung, anstatt ein eigenes Passwort abzufragen. Die Installation besteht aus einer offiziellen Docker-Compose-Datei und zwei generierten Secrets. Der aufwendige Teil folgt danach: Sie müssen einen Reverse Proxy auf Authentik verweisen und eine bereits vorhandene Anwendung hinter Forward Auth schalten.

Authentik wird in dieser Compose-Datei als drei Dienste bereitgestellt: eine PostgreSQL-Datenbank, ein server-Prozess und ein worker-Prozess. Der Server-Container führt außerdem den eingebetteten Outpost aus. Das ist die Komponente, die für jede geschützte Anwendung beantwortet, ob die Anfrage authentifiziert ist. Version 2026.5 ist der aktuelle Release-Stand im Juli 2026. Das Projekt verlangt einen Host mit mindestens 2 CPU-Kernen und 2 GB RAM. Betrachten Sie das als Untergrenze. PostgreSQL und der Worker belegen Speicher, sobald der Server einen Tag lang gelaufen ist.

Voraussetzungen

Sie benötigen Docker Engine mit dem Compose-v2-Plugin. Mit docker compose version können Sie dies überprüfen. Wenn der Befehl statt einer Versionsnummer einen Fehler ausgibt, installieren Sie das Plugin, bevor Sie fortfahren. Die Grundlagen werden in Anwendungen mit Docker Compose auf einem VPS betreiben beschrieben. Außerdem benötigen Sie einen DNS-A-Record, der auf den Server zeigt. In den folgenden Beispielen ist das auth.example.com. Authentik erstellt seine Redirect-URLs anhand des Hostnamens, den der Browser verwendet hat.

Führen Sie den Stack als normaler Benutzer in der Gruppe docker aus, nicht als root. Die Mitgliedschaft in dieser Gruppe entspricht auf dem Host praktisch Root-Rechten. Vergeben Sie sie daher nur an ein Deploy-Konto und an niemanden sonst, wie unter Benutzerkonten mit den geringsten erforderlichen Rechten auf einem VPS beschrieben.

Mit der offiziellen Compose-Datei installieren

sudo install -d -o "$USER" -g "$USER" /opt/authentik
cd /opt/authentik
wget https://docs.goauthentik.io/compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose pull
docker compose up -d

docker compose ps sollte drei Container auflisten. postgresql sollte healthy melden, server sollte worker melden und running sollte melden. Beim ersten Start werden die Datenbankmigrationen ausgeführt. Warten Sie daher eine Minute, bevor die Weboberfläche antwortet.

Beide generierten Werte sind aus unterschiedlichen Gründen wichtig. PG_PASS ist das PostgreSQL-Passwort und darf höchstens 99 Zeichen lang sein. AUTHENTIK_SECRET_KEY signiert Sitzungen und Tokens. Wenn Sie den Wert später ändern, werden alle Benutzer abgemeldet und alle ausgegebenen API-Tokens ungültig. Setzen Sie die Berechtigungen für .env auf 600 und bewahren Sie eine Kopie an einem sicheren Ort auf. Eine Datenbank ohne den zugehörigen geheimen Schlüssel ist eine Datenbank, bei der sich niemand anmelden kann.

Die Compose-Datei liest beide Werte mit der Form ${PG_PASS:?database password required} ein. Daher startet Compose nicht, wenn die Datei fehlt. Wenn Sie docker compose up -d aus dem falschen Verzeichnis ausführen, wird required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required ausgegeben und der Vorgang beendet. Diese Meldung weist auf ein Pfadproblem hin, nicht auf ein Konfigurationsproblem.

Die relevanten Umgebungsvariablen

Alles andere steht in derselben .env-Datei. Authentik ordnet einen doppelten Unterstrich einem verschachtelten Konfigurationsschlüssel zu. Daher setzt AUTHENTIK_EMAIL__HOST den Wert email.host. Ein einzelner Unterstrich wird ohne Warnung ignoriert. Das ist der häufigste Grund dafür, dass eine Einstellung scheinbar keine Wirkung hat.

• AUTHENTIK_BOOTSTRAP_PASSWORD setzt beim ersten Start das Passwort des integrierten Benutzers akadmin. Sie müssen es daher nie in ein öffentliches Webformular eingeben. AUTHENTIK_BOOTSTRAP_EMAIL und AUTHENTIK_BOOTSTRAP_TOKEN setzen auf dieselbe Weise die Adresse dieses Benutzers und ein API-Token.
• COMPOSE_PORT_HTTP und COMPOSE_PORT_HTTPS verlagern die veröffentlichten Ports weg von den Standardwerten 9000 und 9443.
• AUTHENTIK_EMAIL__HOST, AUTHENTIK_EMAIL__PORT, AUTHENTIK_EMAIL__USERNAME, AUTHENTIK_EMAIL__PASSWORD, AUTHENTIK_EMAIL__USE_TLS und AUTHENTIK_EMAIL__FROM konfigurieren den ausgehenden E-Mail-Versand. Ohne diese Variablen versucht Authentik, localhost über Port 25 zu erreichen. Dadurch enden E-Mails zum Zurücksetzen des Passworts mit einem Verbindungsfehler im Worker-Log.
• AUTHENTIK_LOG_LEVEL=debug aktiviert die Detailstufe, die Sie benötigen, wenn ein Login-Flow fehlerhaft arbeitet. Setzen Sie den Wert anschließend wieder auf info zurück.
• AUTHENTIK_ERROR_REPORTING__ENABLED ist standardmäßig false. Setzen Sie den Wert nur auf true, wenn Sie mit der Übermittlung von Absturzberichten an den Anbieter einverstanden sind.

Diese Werte sind Secrets in einer unverschlüsselten Datei. Behandeln Sie das Verzeichnis daher wie jeden anderen Speicherort für Zugangsdaten. Ein Passwortmanager wie eine selbst gehostete Vaultwarden-Instanz eignet sich besser für die Wiederherstellungskopie als eine Notiz auf Ihrem Laptop.

Erste Anmeldung und das Administratorkonto

Öffnen Sie http://SERVER_IP:9000 in einem Browser. Authentik zeigt den Ablauf für die Ersteinrichtung an und fordert Sie auf, ein Passwort für den standardmäßigen Benutzer akadmin festzulegen. Wenn Sie AUTHENTIK_BOOTSTRAP_PASSWORD bereits festgelegt haben, ist dieser Schritt abgeschlossen, und Sie gelangen direkt zur Anmeldeseite.

Erstellen Sie unter Directory und anschließend Users einen normalen Administratorkonten für sich selbst, fügen Sie es der Gruppe authentik Admins hinzu und melden Sie sich mit diesem Konto an. Belassen Sie akadmin als Notfallkonto und speichern Sie ein langes Passwort dafür offline. Die tägliche Arbeit mit einem gemeinsam verwendeten integrierten Konto zerstört das Audit-Log, weil jedes Ereignis akadmin ausweist und keine Information zur verantwortlichen Person enthält. Das gilt auch für nachgelagerte Systeme hinter Authentik: Etwas wie ein selbst gehostetes OneCLI-Toolkit, das jeder Person einen eigenen Agenten bereitstellt erzeugt nur dann eine nachvollziehbare Spur, wenn die ankommende Identität einer einzelnen Person und nicht einem Login zugeordnet ist, das vom gesamten Team gemeinsam verwendet wird.

Authentik hinter den Reverse Proxy setzen

Port 9000 im Internet zu veröffentlichen funktioniert, aber Sie benötigen TLS (Transport Layer Security) und einen echten Hostnamen. Wenn Sie bereits die Einrichtung aus Traefik als Reverse Proxy für mehrere Compose-Anwendungen verwenden, verbinden Sie Authentik mit einer Override-Datei mit demselben externen proxy-Netzwerk. Erstellen Sie docker-compose.override.yml neben compose.yml:

services:
  server:
    networks:
      - default
      - proxy
    labels:
      traefik.enable: "true"
      traefik.docker.network: proxy
      traefik.http.routers.authentik.rule: Host(`auth.example.com`)
      traefik.http.routers.authentik.entrypoints: websecure
      traefik.http.routers.authentik.tls.certresolver: le
      traefik.http.services.authentik.loadbalancer.server.port: "9000"

networks:
  proxy:
    external: true

Wenden Sie die Datei mit docker compose up -d an. Compose führt die Override-Datei automatisch zusammen. Der Dienst server behält dadurch alle Einstellungen aus der offiziellen Datei und erhält zusätzlich die Labels. Prüfen Sie die Konfiguration mit curl -I https://auth.example.com/if/user/. Der Befehl sollte HTTP/2 200 zurückgeben. Ein 404 page not found von Traefik bedeutet, dass sich der Container nicht im proxy-Netzwerk befindet. Traefik kann keinen Container weiterleiten, den es nicht erreichen kann.

Sobald der Hostname funktioniert, binden Sie die veröffentlichten Ports in der Override-Datei an 127.0.0.1. Der einzige Zugangsweg führt dann über den Proxy.

Eine Anwendung mit Forward Auth schützen

Authentiks Proxy-Provider hat drei Modi. Die Wahl des falschen Modus kostet Sie eine Stunde. Proxy bedeutet, dass der Outpost selbst den Datenverkehr an die Upstream-Anwendung weiterleitet. Forward auth (single application) bedeutet, dass Ihr eigener Reverse Proxy den Datenverkehr weiterhin weiterleitet und Authentik nur prüft, ob die Anfrage authentifiziert ist. Forward auth (domain level) schützt jede Anwendung unter einer gemeinsamen übergeordneten Domain mit einem einzigen Provider. Dafür gelten keine individuellen Autorisierungsregeln pro Anwendung. Wenn Traefik vorgeschaltet ist, benötigen Sie forward auth (single application). Wenn Sie eine konkrete Anwendung zum Üben suchen, ist beispielsweise ein selbst gehosteter AFFiNE-Arbeitsbereich ein guter Ausgangspunkt. Er eignet sich, weil ein solches internes Tool von Ihren eigenen Geräten erreichbar sein soll, aber von nirgendwo sonst. Bei einem Team-Tool ist der Vorteil noch deutlicher: Stellen Sie ein selbst gehostetes Chatwoot-Supportdesk hinter denselben Provider. Dann meldet sich jeder, der das Postfach bearbeitet, einmal pro Tag an, statt ein weiteres Passwort gemeinsam zu verwenden.

Öffnen Sie in der Weboberfläche Applications und anschließend Providers. Erstellen Sie einen Proxy Provider, wählen Sie den Modus forward auth single application und setzen Sie den externen Host auf https://app.example.com. Erstellen Sie eine Application, die auf diesen Provider verweist. Öffnen Sie anschließend Outposts, bearbeiten Sie authentik Embedded Outpost und verschieben Sie die neue Anwendung in die ausgewählten Anwendungen. Der Outpost antwortet nur für Anwendungen, die ihm zugewiesen wurden. Wenn Sie diesen letzten Schritt überspringen, liefert ein korrekt konfigurierter Provider weiterhin keine Antwort.

Definieren Sie die Middleware einmal am Authentik-Container und referenzieren Sie sie von jeder geschützten Anwendung:

      traefik.http.middlewares.authentik.forwardauth.address: http://server:9000/outpost.goauthentik.io/auth/traefik
      traefik.http.middlewares.authentik.forwardauth.trustForwardHeader: "true"
      traefik.http.middlewares.authentik.forwardauth.authResponseHeaders: X-authentik-username,X-authentik-groups,X-authentik-email,X-authentik-name,X-authentik-uid,X-authentik-jwt,X-authentik-meta-jwks,X-authentik-meta-outpost,X-authentik-meta-provider,X-authentik-meta-app,X-authentik-meta-version

authResponseHeaders ist die Liste der Header, die Traefik aus der Antwort von Authentik übernimmt und an die Anfrage an die Upstream-Anwendung anhängt. Wenn Sie diese Liste weglassen, bleibt die Anwendung zwar geschützt. Sie erfährt jedoch nicht, welcher Benutzer angemeldet ist. Alles, was X-authentik-username für die automatische Anmeldung auswertet, bleibt dann abgemeldet. Besonders deutlich wird diese Lücke vor einer Anwendung mit eigener Anmeldung, beispielsweise einem selbst gehosteten openGym-Trainingstracker mit Passkey-Anmeldung. Die Header entscheiden dort, ob dieselbe Seite eine oder zwei Anmeldeaufforderungen auslöst.

Die geschützte Anwendung benötigt zwei Router, nicht einen:

    labels:
      traefik.enable: "true"
      traefik.http.routers.myapp.rule: Host(`app.example.com`)
      traefik.http.routers.myapp.entrypoints: websecure
      traefik.http.routers.myapp.tls.certresolver: le
      traefik.http.routers.myapp.middlewares: authentik@docker
      traefik.http.routers.myapp-auth.rule: Host(`app.example.com`) && PathPrefix(`/outpost.goauthentik.io/`)
      traefik.http.routers.myapp-auth.entrypoints: websecure
      traefik.http.routers.myapp-auth.tls.certresolver: le
      traefik.http.routers.myapp-auth.priority: "15"
      traefik.http.routers.myapp-auth.service: authentik

Der zweite Router wird häufig weggelassen. Nach der Anmeldung leitet Authentik den Browser auf einen Pfad unter /outpost.goauthentik.io/ auf dem Hostnamen der Anwendung zurück, nicht auf auth.example.com. Ohne einen Router, der dieses Pfadpräfix an den Authentik-Dienst weiterleitet, erreicht die Anfrage Ihre Anwendung. Diese antwortet mit 404, und die Anmeldung wird nicht abgeschlossen. Der höhere Wert von priority sorgt dafür, dass die spezifische Pfadregel gegenüber der einfachen Host()-Regel auf derselben Domain Vorrang hat.

Testen Sie die Konfiguration in einem privaten Browserfenster. Sie sollten zu auth.example.com weitergeleitet werden, sich anmelden können und anschließend zur Anwendung zurückkehren. docker compose logs -f server auf der Authentik-Seite gibt für jeden Versuch ein Autorisierungsereignis aus. Damit können Sie prüfen, ob die Anfrage Authentik überhaupt erreicht hat.

Die Fehler, auf die Sie tatsächlich stoßen werden

Endlosschleife bei der Weiterleitung zwischen der Anwendung und der Anmeldeseite. Der externe Host beim Provider stimmt nicht mit dem Host überein, den der Browser verwendet. In der Regel steht beim Provider http://, während in der Adressleiste https:// angezeigt wird. Das Session-Cookie wird dann für eine andere Origin gesetzt. Jeder Rücksprung wirkt dadurch wie eine neue anonyme Anfrage. Korrigieren Sie den externen Host und löschen Sie vor einem erneuten Test die Cookies für beide Domains.

404 bei /outpost.goauthentik.io/start. Der Outpost-Router fehlt, oder seine Priorität ist niedriger als die des Catch-all-Routers für diesen Host.

Die Anwendung wird geladen, ohne nach einer Anmeldung zu fragen. Das Label middlewares verweist auf eine Middleware, die nicht existiert. Traefik gibt dafür keine Warnung aus. Ein Tippfehler in authentik@docker bedeutet daher einfach, dass keine Middleware ausgeführt wird. Öffnen Sie das Traefik-Dashboard und prüfen Sie, ob der Router die Middleware auflistet.

403 von Authentik nach erfolgreicher Anmeldung. Der Benutzer ist authentifiziert, aber nicht autorisiert. Die Anwendung enthält eine Policy-Zuordnung oder eine Gruppenanforderung, die dieser Benutzer nicht erfüllt. Das Events-Log in der Administrationsoberfläche nennt die Policy, die den Zugriff verweigert hat.

Wenn Keycloak die bessere Wahl ist

Keycloak ist das ältere, von Red Hat unterstützte Projekt. Es ist die stärkere Wahl für klassische Identitätsverwaltung im Enterprise-Umfeld: umfangreiche SAML-Föderation, die Bündelung von Anmeldungen mehrerer externer Identity Provider und der Export und Import von Realms als dokumentierter Migrationsweg. Der dahinterstehende kommerzielle Support ist für manche Organisationen auch auf dem Papier relevant. Der Nachteil ist, dass Keycloak keinen eigenen Proxy bereitstellt. Für den Schutz einer Anwendung, die kein OIDC (OpenID Connect) spricht, muss daher beispielsweise oauth2-proxy daneben betrieben werden. Der integrierte Proxy Provider von Authentik übernimmt diese Aufgabe bereits. Deshalb entscheiden sich die meisten Self-Hoster mit einer heterogenen Sammlung von Anwendungen für Authentik.

Backups und Upgrades

Drei Dinge ermöglichen eine Wiederherstellung: die PostgreSQL-Datenbank, das Verzeichnis ./data und .env.

cd /opt/authentik
docker compose exec -T postgresql pg_dump -U authentik authentik | gzip > authentik-$(date +%F).sql.gz

Speichern Sie diesen Dump zusammen mit .env. Der Dump allein reicht nicht aus, weil der geheime Schlüssel zum Schutz von Sitzungs- und Tokendaten in .env liegt.

Upgrades bestehen aus einer Änderung des Tags. Setzen Sie AUTHENTIK_TAG in .env auf das gewünschte Release und führen Sie anschließend docker compose pull und danach docker compose up -d aus. Lesen Sie zuerst die Release Notes, weil Authentik datumsbasierte Versionen verwendet und einige Releases Migrationen enthalten, die voraussetzen, dass Sie vom vorherigen Release aktualisieren. Erstellen Sie den Datenbank-Dump vor dem Pull, nicht danach.

FAQ

Ist Authentik für Self-Hosting kostenlos?

Die Open-Source-Edition ist kostenlos und deckt alle oben genannten Funktionen ab: den Proxy Provider, Forward Auth, OIDC (OpenID Connect), SAML und die Flows Engine. Eine kostenpflichtige Enterprise-Stufe ergänzt Support und einige Enterprise-Funktionen. Für die hier beschriebenen Funktionen ist jedoch keine Lizenz erforderlich.

Benötige ich Traefik für die Verwendung von Authentik?

Nein. Forward Auth funktioniert mit nginx über auth_request und mit Caddy über forward_auth. Das Muster ist in allen Fällen gleich: Der Reverse Proxy fragt Authentik für jede Anfrage ab. Das Pfadpräfix /outpost.goauthentik.io/ auf dem geschützten Hostnamen muss zu Authentik und nicht zur Anwendung weiterleiten.

Warum wechselt meine geschützte Anwendung ständig zwischen Anmeldung und Fehlermeldung?

Der auf dem Proxy Provider konfigurierte externe Host stimmt nicht mit der URL überein, die der Browser verwendet. Am häufigsten tritt das bei http gegenüber https auf. Das Sitzungs-Cookie wird für einen Ursprung ausgestellt und von einem anderen gelesen. Deshalb behandelt Authentik jede Anfrage als anonym. Korrigieren Sie den externen Host. Löschen Sie anschließend die Cookies für beide Hostnamen, bevor Sie den Test wiederholen.

Wie viel RAM benötigt Authentik?

Stand Juli 2026 beträgt das dokumentierte Minimum 2 CPU-Kerne und 2 GB RAM. Damit sind PostgreSQL, der Server und der Worker zusammen abgedeckt. Auf einem System mit 2 GB beendet der Kernel den Worker bei Speicherdruck zuerst. Das äußert sich dadurch, dass Hintergrundaufgaben und der Versand ausgehender E-Mails stoppen, während die Anmeldeseite weiterhin funktioniert. Weisen Sie Authentik 4 GB zu, wenn auf demselben Server zusätzlich die von Ihnen geschützten Anwendungen laufen.