Vaultwarden: SSO mit authentik

Aus maxTechCorner

Auf einen Blick

Gilt fürVaultwarden 1.37.x (SSO ab 1.35), authentik 2026.5 bzw. 2026.8; Bitwarden-Clients ab 2026.x (Web, Browser-Erweiterung, Desktop, Mobil)
BereichIT-Security
Dauerca. 30 Minuten
Rechteauthentik-Administrator; root/sudo auf dem Docker-Host von Vaultwarden
StandOktober 2026

Vaultwarden per SSO mit authentik anbinden bringt den selbst gehosteten Passwortmanager unter die zentrale Benutzerverwaltung: Mitarbeiter melden sich mit ihrem authentik-Konto und dessen Mehr-Faktor-Anmeldung an, und wer in authentik gesperrt wird, verliert auch den Zugang zu Vaultwarden. Diese Anleitung zeigt die Einrichtung über OpenID Connect Schritt für Schritt – inklusive der zwei Stolperfallen, an denen die Anmeldung häufig scheitert: dem Claim email_verified und zu kurz gültigen Tokens.

Vaultwarden mit authentik per SSO: In authentik eine eigene Scope-Zuordnung für email mit email_verified True, eine Anwendung mit OAuth2/OpenID-Provider, strikter Redirect-URI /identity/connect/oidc-signin, Signaturschlüssel ohne Verschlüsselung, Zugriffstoken länger als 5 Minuten und Scope offline_access sowie eine Gruppenbindung anlegen. In Vaultwarden SSO_ENABLED, SSO_AUTHORITY mit abschließendem Schrägstrich, Client-ID, Client-Secret und Scopes setzen. Das Master-Passwort bleibt für die Entschlüsselung des Tresors nötig.

Was SSO bei Vaultwarden leistet – und was nicht

  • Anmeldung: authentik prüft Benutzername, Passwort und zweiten Faktor (z. B. Passkey, TOTP). Vaultwarden vertraut dem Ergebnis per OpenID Connect.
  • Zugriffssteuerung: Nur Mitglieder einer bestimmten authentik-Gruppe dürfen Vaultwarden nutzen. Wird ein Konto in authentik deaktiviert, sind keine neuen Anmeldungen mehr möglich; mit Refresh-Token endet auch die laufende Sitzung, sobald das Zugriffstoken abläuft.
  • Master-Passwort bleibt: Der Tresor wird weiterhin mit dem Master-Passwort des Benutzers entschlüsselt. authentik kann den Tresor nicht öffnen – auch ein Administrator von authentik nicht. Das ist gewollt und gehört zum Sicherheitskonzept von Bitwarden.
  • Keine Benutzer-Synchronisation: SSO legt Konten bei der ersten Anmeldung an bzw. verknüpft sie. Gruppen und Sammlungen in Vaultwarden-Organisationen werden nicht aus authentik übernommen.

Allgemeine Hinweise zu Zwei-Faktor-Anmeldung und SSO mit anderen Anbietern (Entra ID, Keycloak) stehen im Artikel Vaultwarden: Zwei-Faktor-Anmeldung und SSO mit OpenID Connect.

Voraussetzungen

  • Vaultwarden ab 1.35 (empfohlen: aktuelle 1.37.x) mit HTTPS und korrekt gesetzter Variable DOMAIN, siehe Vaultwarden: HTTPS mit Reverse Proxy (Caddy, nginx, OPNsense).
  • authentik ab 2026.5 (für die strikte Redirect-URI wie unten beschrieben), siehe authentik.
  • Der Vaultwarden-Container muss authentik per HTTPS erreichen können. Bei Zertifikaten einer eigenen CA das Stammzertifikat im Container hinterlegen (SSL_CERT_FILE bzw. SSL_CERT_DIR).
  • E-Mail-Adressen der Benutzer in authentik stimmen mit den Adressen in Vaultwarden überein.

Schritt 1: Scope-Zuordnung für die E-Mail-Adresse anlegen

Seit authentik 2025.10 liefert die Standard-Zuordnung für den Scope email den Wert email_verified: false. Vaultwarden lehnt die Anlage eines Kontos mit unbestätigter E-Mail-Adresse ab. Deshalb wird eine eigene Zuordnung benötigt:

  1. In authentik Customization → Property Mappings öffnen und Create wählen.
  2. Typ Scope Mapping, Name z. B. Vaultwarden Email Scope, Scope name email.
  3. Als Expression eintragen und mit Finish speichern:
return {
    "email": request.user.email,
    "email_verified": True,
}
WarnungDie Zuordnung bestätigt die E-Mail-Adresse jedes Benutzers. Verwenden Sie sie nur, wenn die Adressen in authentik von der IT gepflegt werden (z. B. aus Active Directory oder Entra ID) und Benutzer ihre Adresse nicht selbst ändern können.

Schritt 2: Anwendung und OAuth2/OpenID-Provider anlegen

  1. Applications → Applications öffnen und New Application wählen.
  2. Application: Name Vaultwarden, Slug z. B. vaultwarden (wird für die Authority-URL benötigt), optional Gruppe und Symbol.
  3. Provider type: OAuth2/OpenID Connect.
  4. Provider:
    • Client type Confidential; Client ID und Client Secret notieren.
    • Redirect URIs: Typ Strict / Authorization mit https://vault.example.com/identity/connect/oidc-signin.
    • Signing Key: einen Schlüssel auswählen, z. B. das mitgelieferte authentik Self-signed Certificate.
    • Encryption Key: leer lassen – Vaultwarden kann verschlüsselte Tokens (JWE) nicht verarbeiten.
  5. Advanced protocol settings:
    • Access token validity: mehr als 5 Minuten, z. B. minutes=10 – sonst kollidiert der Ablauf mit der Token-Prüfung der Bitwarden-Clients.
    • Refresh token validity: z. B. days=7; bestimmt, wie lange eine inaktive Sitzung hält.
    • Scopes: authentik default OAuth Mapping: OpenID 'openid' und … 'profile' behalten, die Standardzuordnung … 'email' entfernen und stattdessen Vaultwarden Email Scope aus Schritt 1 sowie authentik default OAuth Mapping: OpenID 'offline_access' hinzufügen.
  6. Mit Submit speichern.

Schritt 3: Zugriff auf eine Gruppe beschränken

  1. Unter Directory → Groups eine Gruppe wie Vaultwarden-Benutzer anlegen und die berechtigten Benutzer aufnehmen.
  2. In der Anwendung Vaultwarden unter Policy / Group / User Bindings die Gruppe binden.

Ohne Bindung dürfen sich alle authentik-Benutzer anmelden. Mehr-Faktor-Anmeldung wird über den Anmelde-Flow von authentik erzwungen (z. B. Authenticator-Validierung mit Passkey oder TOTP).

Schritt 4: Vaultwarden konfigurieren

Die Variablen in der .env bzw. im Abschnitt environment der Docker-Compose-Datei ergänzen (siehe Vaultwarden: Installation mit Docker Compose): 

DOMAIN=https://vault.example.com
SSO_ENABLED=true
SSO_AUTHORITY=https://auth.example.com/application/o/vaultwarden/
SSO_CLIENT_ID=<Client ID aus authentik>
SSO_CLIENT_SECRET=<Client Secret aus authentik>
SSO_SCOPES=email profile offline_access
SSO_SIGNUPS_MATCH_EMAIL=true
SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
SSO_ONLY=false

Anschließend den Container neu erstellen: 

docker compose up -d
docker compose logs -f vaultwarden
  • SSO_AUTHORITY muss exakt dem Wert issuer entsprechen, den authentik unter https://auth.example.com/application/o/vaultwarden/.well-known/openid-configuration ausliefert – bei authentik mit abschließendem Schrägstrich.
  • SSO_SIGNUPS_MATCH_EMAIL=true verknüpft bei der ersten SSO-Anmeldung ein bestehendes Vaultwarden-Konto mit gleicher E-Mail-Adresse.
  • SSO_SIGNUPS_ALLOWED (Standard true) erlaubt, dass SSO neue Konten anlegt. Wer neue Benutzer nur per Einladung aufnehmen will, setzt den Wert auf false.
  • Das Client-Secret gehört nicht in ein Git-Repository; bei Docker Compose am besten in einer .env mit eingeschränkten Rechten ablegen.

Schritt 5: Anmeldung testen und Benutzer umstellen

  1. Aus Vaultwarden abmelden, die Weboberfläche öffnen, die E-Mail-Adresse eingeben und Single Sign-On verwenden wählen.
  2. Vaultwarden leitet zu authentik weiter; nach der Anmeldung (inkl. zweitem Faktor) kehrt der Browser zurück.
  3. Bestehende Benutzer entsperren den Tresor wie gewohnt mit ihrem Master-Passwort. Neue Benutzer legen bei der ersten Anmeldung ein Master-Passwort fest.
  4. Browser-Erweiterung, Desktop- und Mobil-App bieten die SSO-Anmeldung ebenfalls an; bei der Desktop-App muss der Browser die Rückleitung an die App (bitwarden://) zulassen.
  5. Wenn alle Benutzer umgestellt sind, kann die Anmeldung mit E-Mail und Master-Passwort ohne SSO abgeschaltet werden: SSO_ONLY=true. Die Admin-Oberfläche /admin ist davon nicht betroffen und bleibt über das Admin-Token erreichbar.

Fehlerbehebung

Meldung bzw. Verhalten Ursache und Lösung
Failed to discover OpenID provider SSO_AUTHORITY falsch (Schrägstrich, Slug) oder authentik aus dem Container nicht erreichbar. Mit docker compose exec vaultwarden curl …/.well-known/openid-configuration prüfen. Liefert die Antwort HS256 statt RS256, im Provider einen Signing Key auswählen.
Invalid JSON web token: found 5 parts Im Provider ist ein Encryption Key gesetzt – auf leer stellen.
Konto wird nicht angelegt, Hinweis auf unbestätigte E-Mail Standard-Zuordnung email noch aktiv – durch die eigene Zuordnung aus Schritt 1 ersetzen.
Abmeldung nach wenigen Minuten Zugriffstoken zu kurz oder offline_access fehlt in Provider bzw. SSO_SCOPES.
redirect_uri passt nicht DOMAIN in Vaultwarden und Redirect-URI in authentik müssen exakt übereinstimmen (Protokoll, Hostname, Pfad).
Anmeldung abgelehnt trotz korrekter Daten Benutzer ist nicht Mitglied der gebundenen Gruppe.

Für die Fehlersuche kann vorübergehend LOG_LEVEL=info,vaultwarden::sso=debug gesetzt werden; danach wieder zurückstellen.

Sicherheit und Betrieb

  • SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION nicht einschalten: Zusammen mit SSO_SIGNUPS_MATCH_EMAIL=true könnte sonst ein Benutzer ein fremdes Konto mit gleicher Adresse übernehmen (den Tresor ohne Master-Passwort aber nicht öffnen).
  • Verfügbarkeit von authentik: Mit SSO_ONLY=true hängt jede Anmeldung an authentik. Für den Notfall dokumentieren, wie SSO vorübergehend abgeschaltet wird, und authentik in die Datensicherung aufnehmen.
  • Anbieter wechseln: Vaultwarden speichert die Zuordnung zum IdP in der Tabelle sso_users. Bei einem Wechsel des Anbieters oder der URL muss diese Zuordnung gelöscht werden, damit sich die Konten neu verknüpfen.
  • Master-Passwort-Richtlinie: Über SSO_MASTER_PASSWORD_POLICY lassen sich Mindestlänge und Komplexität für SSO-Benutzer vorgeben.
  • Updates: Vaultwarden und authentik regelmäßig aktualisieren; Outposts von authentik müssen dieselbe Version wie der Server haben.

Unterstützung von m.a.x. it

Sie möchten Vaultwarden mit authentik oder einem anderen Identity Provider zentral absichern? m.a.x. it unterstützt Sie bei Einrichtung, Härtung und Betrieb – mit Cybersecurity-Leistungen von m.a.x. it rund um Identitäten, Passwörter und Zugriffsschutz.

Siehe auch

Links und Quellen


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen

Abgerufen von „https://techcorner.max-it.de/index.php?title=Vaultwarden:_SSO_mit_authentik&oldid=5190“