Authentik mit Docker Compose als SSO einrichten

Eine Anmeldung 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 anzufordern. Die Installation besteht aus einer offiziellen Docker-Compose-Datei und zwei generierten Geheimnissen. Der aufwendige Teil folgt danach: Sie müssen einen Reverse Proxy darauf verweisen und eine vorhandene Anwendung hinter Forward Auth setzen.

Authentik wird in dieser Compose-Datei als drei Dienste ausgeführt: eine PostgreSQL-Datenbank, ein server-Prozess und ein worker-Prozess. Der Server-Container führt außerdem den eingebetteten Outpost aus. Diese Komponente beantwortet für jede geschützte Anwendung die Frage: „Ist diese Anfrage authentifiziert?“ Version 2026.8.5 ist am 25 October 2026 die aktuelle Version. Sie wurde am 21 October 2026 als neuester Patch der Serie 2026.8 veröffentlicht. Diese Serie begann am 18 August mit 2026.8.0. Version 2026.8.5 ersetzt 2026.8.4 vom 14 October als Standard-Image-Tag in der offiziellen Compose-Datei. 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 Host einen Tag lang in Betrieb war.

Was Sie vor dem Start benötigen

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 Versionsangabe einen Fehler ausgibt, installieren Sie das Plugin, bevor Sie fortfahren. Die Grundlagen werden unter Anwendungen mit Docker Compose auf einem VPS ausführen beschrieben. Außerdem benötigen Sie einen DNS-A-Record, der auf den Server zeigt. In den folgenden Beispielen ist dies 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 den Rechten von root. Vergeben Sie sie daher nur an ein Deploy-Konto und an keine weiteren Benutzer. Orientierung bietet Benutzerkonten mit geringsten erforderlichen Rechten auf einem VPS.

Installation mit der offiziellen Compose-Datei

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 anzeigen, die alle laufen. postgresql sollte healthy melden, sobald die Prüfung erfolgreich ist. Beim ersten Start werden die Datenbankmigrationen ausgeführt. Warten Sie daher eine Minute, bevor die Weboberfläche antwortet.

Beide generierten Werte sind wichtig, jedoch aus unterschiedlichen Gründen. PG_PASS ist das PostgreSQL-Passwort. Die Installationsdokumentation von Authentik weist darauf hin, dass Passwörter mit mehr als 99 Zeichen nicht unterstützt werden. Halten Sie ein selbst gewähltes Passwort daher unter dieser Länge. Das generierte Passwort ist deutlich kürzer. AUTHENTIK_SECRET_KEY ist der Schlüssel, mit dem Authentik Cookies signiert. Die Konfigurationsdokumentation weist darauf hin, dass eine Änderung aktive Sitzungen ungültig macht. Ein später neu gesetzter Schlüssel meldet daher jeden angemeldeten Benutzer ab. Lassen Sie .env auf dem Modus 600 und bewahren Sie eine Kopie zusammen mit Ihren Backups an einem sicheren Ort auf. Nach einer Wiederherstellung wird dann derselbe Schlüssel verwendet wie zuvor.

Die Compose-Datei markiert beide Werte mit der ${VAR:?message}-Syntax als erforderlich: ${PG_PASS:?database password required} beim PostgreSQL-Dienst und ${AUTHENTIK_SECRET_KEY:?secret key required} beim Server und Worker. Compose verweigert den Start, wenn die Datei fehlt. Wird docker compose up -d aus dem falschen Verzeichnis ausgeführt, wird eine Zeile wie required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required ausgegeben und der Vorgang beendet. Das ist ein Pfadproblem und kein Konfigurationsproblem.

Die relevanten Umgebungsvariablen

Alles Weitere 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 nicht auf den verschachtelten Schlüssel abgebildet. 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 akadmin-Benutzers. Sie müssen es daher nie in ein öffentlich erreichbares 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 verschieben die veröffentlichten Ports von den Standardports 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 auf false gesetzt. 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 Klartextdatei. 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 akadmin-Benutzer festzulegen. Wenn Sie AUTHENTIK_BOOTSTRAP_PASSWORD bereits gesetzt haben, ist dieser Schritt abgeschlossen und Sie gelangen direkt zur Anmeldeseite.

Erstellen Sie unter Directory und anschließend Users einen normalen Administrat Benutzer für sich selbst. Fügen Sie ihn der Gruppe authentik Admins hinzu und melden Sie sich mit diesem Konto an. Lassen Sie akadmin als Notfallkonto bestehen und speichern Sie dafür ein langes Passwort offline. Wenn ein fehlerhafter Flow oder eine fehlerhafte Stage Sie aussperrt, gibt docker compose run --rm server create_recovery_key 10 akadmin, ausgeführt aus /opt/authentik, einen Link aus, der Sie direkt als akadmin anmeldet. Jeder, der diesen Link besitzt, hat denselben Zugriff. Behandeln Sie ihn daher wie ein Passwort. Die tägliche Arbeit mit einem gemeinsam genutzten integrierten Konto zerstört das Audit-Log, weil jedes Ereignis akadmin angibt und keine Information darüber enthält, wer die Aktion ausgeführt hat. Das gilt auch hinter Authentik: Etwas wie ein selbst gehostetes OneCLI-System, das jeder Person einen eigenen Agenten bereitstellt erzeugt nur dann eine nachvollziehbare Spur, wenn die ankommende Identität zu einer einzelnen Person gehört und nicht zu einem Login, den das gesamte Team gemeinsam verwendet.

Authentik hinter Ihrem Reverse Proxy betreiben

Port 9000 im Internet zu veröffentlichen funktioniert, aber Sie benötigen TLS (Transport Layer Security) und einen echten Hostnamen. Wenn Sie bereits die Konfiguration aus Traefik als Reverse Proxy für mehrere Compose-Anwendungen verwenden, verbinden Sie Authentik mithilfe 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 mit HTTP/2 200 antworten. Ein 404 page not found von Traefik bedeutet, dass kein Router zur Anfrage gepasst hat. Prüfen Sie, ob die Labels den Container erreicht haben, ob die Host()-Regel exakt mit dem Hostnamen übereinstimmt und ob die Anfrage am HTTPS-Einstiegspunkt angekommen ist, an dem der Router lauscht.

Sobald der Hostname funktioniert, binden Sie die veröffentlichten Ports in der Override-Datei an 127.0.0.1. Der Zugriff ist dann nur noch über den Proxy möglich.

Eine Anwendung mit Forward Auth schützen

Der Proxy Provider von Authentik hat drei Modi. Die Wahl des falschen Modus kostet schnell 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 fragt, ob die Anfrage authentifiziert ist. Forward auth (domain level) schützt jede Anwendung unter einer übergeordneten Domain mit einem einzigen Provider. Dafür fehlen Autorisierungsregeln pro Anwendung. Wenn Traefik vorgeschaltet ist, benötigen Sie forward auth (single application). Wenn Sie eine konkrete Anwendung zum Üben benötigen, ist beispielsweise ein selbst gehosteter AFFiNE-Arbeitsbereich ein guter erster Kandidat. Eine solche interne Anwendung soll von Ihren eigenen Geräten, aber von keinem anderen Ort erreichbar sein. Für eine Team-Anwendung spricht das noch stärker: Stellen Sie einen selbst gehosteten 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 den authentik Embedded Outpost und nehmen Sie die neue Anwendung in die ausgewählten Anwendungen auf. Der Outpost beantwortet nur Anfragen für Anwendungen, die ihm zugewiesen wurden. Wenn dieser letzte Schritt fehlt, liefert ein korrekt konfigurierter Provider deshalb weiterhin keine Antwort.

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

      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-entitlements,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 in die Anfrage an die Upstream-Anwendung übernimmt. Wenn diese Liste fehlt, ist die Anwendung weiterhin geschützt. Sie erfährt jedoch nicht, welcher Benutzer angemeldet ist. Alles, was X-authentik-username für die automatische Anmeldung auswertet, bleibt daher abgemeldet. Besonders deutlich wird diese Lücke bei einer Anwendung mit eigener Anmeldung, beispielsweise einem selbst gehosteten openGym-Workout-Tracker mit Passkey-Anmeldung. Die Header entscheiden dort, ob dieselbe Seite eine oder zwei Anmeldeaufforderungen anzeigt.

Die geschützte Anwendung benötigt zwei Router, nicht nur 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 sendet Authentik den Browser an einen Pfad unter /outpost.goauthentik.io/ auf dem Hostnamen der Anwendung, nicht auf auth.example.com. Ohne einen Router, der diesen 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 für dieselbe Domain Vorrang erhält.

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 protokolliert für jeden Versuch ein Autorisierungsereignis. Daran erkennen Sie, ob die Anfrage Authentik überhaupt erreicht hat.

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

Endlosschleife zwischen der Anwendung und der Anmeldeseite. Der externe Host beim Provider stimmt nicht mit dem Host überein, den der Browser verwendet, normalerweise http:// beim Provider und https:// in der Adressleiste. Das Sitzungscookie wird dann für eine andere Origin gesetzt. Jeder erneute Aufruf erscheint dadurch als 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. Alternativ hat er eine niedrigere Priorität als der Catch-all-Router für diesen Host.

Die Anwendung wird geladen, ohne eine Anmeldung anzufordern. Das Label middlewares verweist auf eine Middleware, die nicht existiert. Traefik gibt dafür keine Warnung aus. Ein Tippfehler in authentik@docker bedeutet daher lediglich, 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 einer erfolgreichen Anmeldung. Der Benutzer ist authentifiziert, aber nicht autorisiert. Für die Anwendung ist eine Policy-Bindung oder eine Gruppenanforderung konfiguriert, 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 und die stärkere Wahl für klassische Enterprise-Identitätsverwaltung: umfangreiche SAML-Föderation, die Vermittlung von Anmeldungen über mehrere externe Identity Provider gleichzeitig sowie der Export und Import von Realms als dokumentierter Migrationspfad. Der dahinterstehende kommerzielle Support ist für manche Unternehmen zumindest auf dem Papier relevant. Der Nachteil ist, dass Keycloak keinen eigenen Proxy bereitstellt. Um eine Anwendung abzusichern, die weder OIDC (OpenID Connect) noch SAML unterstützt, müssen Sie daher beispielsweise oauth2-proxy daneben betreiben. Der integrierte Proxy Provider von Authentik übernimmt diese Funktion bereits. Deshalb entscheiden sich die meisten Self-Hoster mit einer gemischten Sammlung von Anwendungen für Authentik.

Backups und Upgrades

Drei Dinge machen eine Wiederherstellung möglich: 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 und .env gemeinsam. Der Dump enthält keine Kopie von AUTHENTIK_SECRET_KEY. Eine Wiederherstellung mit einem anderen Schlüssel macht alle aktiven Sitzungen ungültig. Wenn Sie den ursprünglichen Schlüssel aufbewahren, kann der wiederhergestellte Server daher mit demselben Sitzungsstatus weiterarbeiten.

Upgrades bestehen aus einer Änderung des Tags. Setzen Sie AUTHENTIK_TAG in .env auf die gewünschte Version. Führen Sie anschließend docker compose pull und danach docker compose up -d aus. Wenn Sie AUTHENTIK_TAG nie setzen, stammt die Version aus dem Standardwert, der direkt in compose.yml eingetragen ist. Das Herunterladen einer neueren Kopie dieser Datei ist dann das Upgrade. Dies ist auch der von der offiziellen Upgrade-Dokumentation beschriebene Weg. Lesen Sie zuerst die Release Notes. Authentik verwendet datumsbasierte Versionsnummern. Stand October 2026 weist die Dokumentation darauf hin, dass Upgrades der Reihenfolge der Major-Releases folgen müssen: Aktualisieren Sie zunächst auf den neuesten Patch der aktuell verwendeten Serie. Durchlaufen Sie anschließend jede spätere Serie in der richtigen Reihenfolge, ohne eine Serie zu überspringen. Authentik unterstützt kein Downgrade. Erstellen Sie den Datenbankdump daher vor dem Pull und nicht danach.

FAQ

Ist Authentik für das 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 bietet Support und einige Enterprise-Funktionen. Für die hier beschriebenen Funktionen benötigen Sie jedoch keine Lizenz.

Benötige ich Traefik für Authentik?

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

Warum wechselt meine geschützte Anwendung dauerhaft zwischen Anmeldung und Fehler?

Der auf dem Proxy-Provider konfigurierte externe Host stimmt nicht mit der URL überein, die der Browser verwendet. Häufig tritt das bei http gegenüber https auf. Das Sitzungs-Cookie wird für einen Ursprung ausgestellt und von einem anderen gelesen. Deshalb sieht Authentik bei jeder Anfrage einen nicht authentifizierten Benutzer. Korrigieren Sie den externen Host. Löschen Sie anschließend die Cookies für beide Hostnamen, bevor Sie erneut testen.

Wie viel RAM benötigt Authentik?

Die dokumentierte Mindestanforderung beträgt seit Oktober 2026 2 CPU-Kerne und 2 GB RAM für PostgreSQL, den Server und den Worker zusammen. Auf einem Server mit 2 GB RAM kann Speicherdruck den OOM-Killer des Kernels auslösen. Dieser beendet den Prozess mit dem höchsten Badness-Score. Der Score entspricht ungefähr dem Anteil des zulässigen Speichers, den der Prozess verwendet, plus seinem oom_score_adj. Wenn dies der Worker ist, werden Hintergrundaufgaben und ausgehende E-Mails beendet, während die Anmeldeseite weiterhin funktioniert. Geben Sie dem Server 4 GB RAM, wenn darauf auch die Anwendungen ausgeführt werden, die Sie schützen.