Authentik mit Vaultwarden verbinden — OIDC Single Sign-On für eure Passwörter

Vaultwarden mit Authentik per OIDC absichern: Single Sign-On für deinen Passwort-Manager. Konfiguration Schritt für Schritt mit Provider-Setup, Bitwarden-Client und 2FA.

💡 Hinweis: Dieses Tutorial setzt voraus, dass du bereits Vaultwarden und Authentik auf deinem Server laufen hast. Beide müssen über HTTPS erreichbar sein.

Einleitung — Warum SSO für Vaultwarden?

Ihr habt Vaultwarden eingerichtet, weil ihr eure Passwörter selbst hosten wollt — die Logik dahinter: Volle Kontrolle, keine fremden Server. Aber Vaultwarden bringt seine eigene Login-Maske mit. Eigene Benutzerverwaltung. Eigene 2FA-Konfiguration. Bei zehn Self-Hosted-Diensten habt ihr zehn Login-Masken zu verwalten.

Wenn ihr Authentik als zentralen Identity Provider laufen habt, könnt ihr Vaultwarden über OpenID Connect (OIDC) dort anbinden. Resultat: Ein Login für Vaultwarden, Gitea, Nextcloud und alle anderen Dienste — gleiche 2FA, gleiche Passwort-Policies, zentrales Audit-Log.

Was diese Integration bringt

• Ein einziger Login für alle Self-Hosted-Dienste
• Zentrale 2FA — In Authentik konfigurieren, gilt automatisch auch für Vaultwarden
• Account-Lifecycle zentral steuern — Mitarbeiter raus, in Authentik deaktivieren, alle Zugänge weg
• Audit-Log — Jeder Login wird in Authentik protokolliert
• Passwort-Reset über Authentik — Vaultwarden muss nicht selbst E-Mails verschicken

⚠️ Wichtig: Vaultwarden ist ein Passwort-Manager. Wenn euer SSO-System (Authentik) ausfällt, kommt ihr nicht mehr an eure Passwörter. Aktiviert SSO_ONLY nicht sofort — lasst den klassischen Login als Fallback aktiv, bis ihr sicher seid, dass alles stabil läuft.

In diesem Guide bauen wir die Verbindung zwischen Authentik und Vaultwarden Schritt für Schritt auf.

Voraussetzungen

• Authentik läuft unter eigener Domain (z.B. auth.example.com)
• Vaultwarden läuft unter eigener Domain (z.B. vault.example.com)
• Beide haben gültige SSL-Zertifikate
• Ihr habt Admin-Zugriff auf beide

Vaultwarden-Version prüfen

OIDC-Support ist in Vaultwarden ab Version 1.34.x stabil verfügbar. Prüfen:

docker exec vaultwarden /vaultwarden --version

docker exec vaultwarden /vaultwarden --version

Falls eure Version älter ist, vorher updaten — siehe Vaultwarden-Tutorial.

Schritt 1: OAuth2/OIDC-Provider in Authentik anlegen

Loggt euch ins Authentik Admin Interface unter https://auth.example.com ein.

Provider erstellen

1. Applications → Providers → Create
2. Wählt OAuth2/OpenID Provider
3. Konfiguration:
   • Name: vaultwarden-provider
   • Authorization flow: default-provider-authorization-implicit-consent
   • Client type: Confidential
   • Client ID: Wird automatisch generiert — gleich kopieren
   • Client Secret: Wird automatisch generiert — gleich kopieren
   • Redirect URIs / Origins: https://vault.example.com/identity/connect/oidc-signin
   • Signing Key: authentik Self-signed Certificate
4. Advanced Settings aufklappen:
   • Subject mode: Based on the User's Email
   • Include claims in id_token: aktiviert lassen
5. Create

⚠️ Wichtig: Die Redirect URI muss exakt so eingetragen werden, wie Vaultwarden sie aufruft. Tippfehler hier sind die häufigste Ursache für „Invalid redirect_uri“-Fehler beim Login.

Application erstellen

Eine Provider ohne Application kann nicht genutzt werden:

1. Applications → Applications → Create
2. Konfiguration:
   • Name: Vaultwarden
   • Slug: vaultwarden
   • Provider: vaultwarden-provider (eben angelegt)
   • Launch URL: https://vault.example.com
   • Icon (optional): Vaultwarden-Logo hochladen
3. Create

Verbindungsdaten merken

Klickt auf den Provider → Tab Overview. Ihr braucht gleich:

Client ID:     [aus Provider-Übersicht kopieren]
Client Secret: [aus Provider-Übersicht kopieren]
Issuer URL:    https://auth.example.com/application/o/vaultwarden/

Client ID:     [aus Provider-Übersicht kopieren]
Client Secret: [aus Provider-Übersicht kopieren]
Issuer URL:    https://auth.example.com/application/o/vaultwarden/

Schritt 2: Vaultwarden für OIDC konfigurieren

Vaultwarden bekommt seine SSO-Konfiguration über Environment Variables. Wir erweitern eure bestehende docker-compose.yml.

sudo nano /opt/vaultwarden/docker-compose.yml

sudo nano /opt/vaultwarden/docker-compose.yml

Ergänzt den environment:-Block des Vaultwarden-Service:

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      # ... eure bestehenden Variablen ...

      # SSO-Konfiguration
      SSO_ENABLED: "true"
      SSO_ONLY: "false"
      SSO_AUTHORITY: "https://auth.example.com/application/o/vaultwarden/"
      SSO_CLIENT_ID: "EURE_CLIENT_ID_AUS_AUTHENTIK"
      SSO_CLIENT_SECRET: "EUER_CLIENT_SECRET_AUS_AUTHENTIK"
      SSO_SCOPES: "email profile openid"
      SSO_PKCE: "true"
      SSO_SIGNUPS_MATCH_EMAIL: "true"
    volumes:
      - ./data:/data
    ports:
      - "127.0.0.1:8080:80"

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      # ... eure bestehenden Variablen ...

      # SSO-Konfiguration
      SSO_ENABLED: "true"
      SSO_ONLY: "false"
      SSO_AUTHORITY: "https://auth.example.com/application/o/vaultwarden/"
      SSO_CLIENT_ID: "EURE_CLIENT_ID_AUS_AUTHENTIK"
      SSO_CLIENT_SECRET: "EUER_CLIENT_SECRET_AUS_AUTHENTIK"
      SSO_SCOPES: "email profile openid"
      SSO_PKCE: "true"
      SSO_SIGNUPS_MATCH_EMAIL: "true"
    volumes:
      - ./data:/data
    ports:
      - "127.0.0.1:8080:80"

Was die Environment Variables bedeuten

💡 Hinweis: SSO_ONLY: "false" ist der sichere Default. Behaltet den klassischen Login als Backup, bis ihr mehrfach erfolgreich per SSO eingeloggt habt. Erst dann auf true umstellen.

Vaultwarden neu starten

cd /opt/vaultwarden
sudo docker compose up -d

cd /opt/vaultwarden
sudo docker compose up -d

Logs prüfen:

sudo docker compose logs -f vaultwarden

sudo docker compose logs -f vaultwarden

Bei Configured SSO authority ist alles gut. Falls Fehler erscheinen, prüft die URLs (Trailing-Slash beachten!) und Credentials.

Schritt 3: Login testen

Öffnet https://vault.example.com in einem frischen Browser-Tab (oder Inkognito-Modus, damit alte Sessions nicht stören).

Erstmaliger SSO-Login

1. Auf der Login-Seite seht ihr jetzt einen Button Enterprise Single Sign-On
2. Klickt darauf
3. Es erscheint ein Feld Identifier — gebt eure Organization-ID ein (oder bei privaten Setups eure E-Mail-Adresse)
4. Ihr werdet zu auth.example.com weitergeleitet
5. Loggt euch dort mit eurem Authentik-Account ein
6. Authentik fragt einmalig nach Zustimmung zur Datenfreigabe → Ja
7. Zurück bei Vaultwarden — eingeloggt!

✅ Geschafft! Vaultwarden authentifiziert euch jetzt über Authentik. 2FA, Passwort-Policies und Account-Verwaltung läuft zentral.

Schritt 4: Bitwarden-Clients konfigurieren

Mobile Apps und Browser-Extensions müssen wissen, dass sie SSO nutzen sollen.

Mobile App (iOS / Android)

1. App öffnen → Anmelden
2. Server-URL auf https://vault.example.com setzen
3. Mit Single Sign-On anmelden wählen
4. Identifier eingeben — gleiche wie im Browser
5. SSO-Flow wie oben

Browser-Extension

1. Extension öffnen → unten Anmelden
2. Region: Selbst gehostet → eure Domain eintragen
3. Mit SSO anmelden wählen
4. Identifier → SSO-Flow

Desktop-App

Identisch mit der Mobile-App — Server-URL setzen, dann SSO wählen.

💡 Tipp: Ein guter Identifier ist eure E-Mail-Domain (z.B. example.com). Damit findet Vaultwarden direkt den richtigen Authentik-Tenant. Bei Multi-Org-Setups nutzt ihr unterschiedliche Identifier pro Org.

Schritt 5: 2FA über Authentik nutzen

Wenn ihr in Authentik bereits MFA-Stages konfiguriert habt (siehe Authentik-Tutorial), greift die 2FA automatisch beim SSO-Login von Vaultwarden.

Vaultwarden-eigene 2FA deaktivieren

Wenn 2FA jetzt zentral über Authentik läuft, ist die Vaultwarden-eigene 2FA überflüssig. Pro Benutzer in Vaultwarden:

• Account-Settings → Two-step Login → Manage → bestehende 2FA-Provider deaktivieren

⚠️ Wichtig: Deaktiviert Vaultwarden-2FA erst, nachdem ihr mehrfach erfolgreich per SSO mit Authentik-2FA eingeloggt habt. Sonst sperrt ihr euch im Worst Case selbst aus.

Schritt 6: Bestehende Vaultwarden-Accounts migrieren

Wenn ihr Vaultwarden schon länger nutzt, habt ihr Accounts mit klassischen Passwörtern. Diese müssen nicht neu angelegt werden — Vaultwarden mappt sie über die E-Mail-Adresse.

Automatisches Matching aktivieren

Das machen wir bereits mit SSO_SIGNUPS_MATCH_EMAIL: "true". Wichtig:

• In Authentik muss der User dieselbe E-Mail haben wie im bestehenden Vaultwarden-Account
• Wenn ihr Authentik-User aus Active Directory / LDAP synct, prüft, ob die E-Mails korrekt übernommen werden

Erster SSO-Login eines Bestands-Users

1. User loggt sich klassisch in Vaultwarden aus
2. User klickt Enterprise Single Sign-On
3. SSO-Flow → Authentik
4. Vaultwarden erkennt die E-Mail und verknüpft den bestehenden Account

Ab jetzt geht beides — SSO und klassischer Login mit dem alten Passwort. Sobald ihr SSO_ONLY: "true" setzt, geht nur noch SSO.

SSO_ONLY aktivieren — der Punkt der Wahrheit

Wenn alle Nutzer mehrfach erfolgreich per SSO eingeloggt waren:

sudo nano /opt/vaultwarden/docker-compose.yml

sudo nano /opt/vaultwarden/docker-compose.yml

SSO_ONLY: "true"

SSO_ONLY: "true"

Vaultwarden neu starten:

cd /opt/vaultwarden
sudo docker compose up -d

cd /opt/vaultwarden
sudo docker compose up -d

Ab jetzt geht der klassische Login nicht mehr. Alle Nutzer müssen SSO verwenden.

⚠️ Best Practice: Bevor ihr SSO_ONLY aktiviert, dokumentiert den Notfall-Plan: Wie kommt ihr an eure Passwörter, wenn Authentik mal nicht erreichbar ist? Empfehlung: Mindestens ein Notfall-Account, dessen Master-Passwort ihr offline (z.B. in einem Safe) hinterlegt habt.

Troubleshooting

„Invalid redirect_uri“

• In Authentik Provider → Redirect URIs prüfen
• Muss exakt https://vault.example.com/identity/connect/oidc-signin sein
• Trailing-Slash beachten (oder weglassen — beides muss konsistent sein)

„SSO_AUTHORITY not reachable“

docker exec vaultwarden curl -sI https://auth.example.com/application/o/vaultwarden/.well-known/openid-configuration

docker exec vaultwarden curl -sI https://auth.example.com/application/o/vaultwarden/.well-known/openid-configuration

• Liefert das HTTP/2 200? Falls nicht: Authentik-Server-Erreichbarkeit prüfen
• Container kann externe DNS auflösen? docker exec vaultwarden nslookup auth.example.com

„User does not exist“

SSO_SIGNUPS_MATCH_EMAIL: "true" ist gesetzt? Plus: User in Authentik hat die korrekte E-Mail-Adresse hinterlegt?

In Authentik: Directory → Users → [User] → Tab "Profile" → "E-mail"

In Authentik: Directory → Users → [User] → Tab "Profile" → "E-mail"

„Token validation failed“

• SSO_PKCE: "true" und in Authentik Client type: Confidential — beide Settings müssen stimmen
• Authentik Worker läuft? docker compose logs authentik-worker

Login funktioniert, aber Bitwarden Mobile App akzeptiert SSO nicht

• App-Version aktuell? Bitwarden hat SSO-Bugs in alten Versionen
• In Authentik Subject mode auf Based on the User's Email gesetzt?

„Account already exists“

Tritt auf, wenn ein User per E-Mail nicht eindeutig ist. In Authentik nur einen User pro E-Mail anlegen, dann erneut versuchen.

Zusammenfassung & Checkliste

Nächste Schritte

• Authentik mit Gitea verbinden — gleiche Logik, anderer Service
• Authentik Federation — GitHub/Google als Login-Quelle für eure Authentik-User
• Audit-Log auswerten — In Authentik unter Events seht ihr jeden Login

Habt ihr Fragen oder Probleme? Schreibt es in die Kommentare — ich helfe gerne!