Passkeys verändern die Art, wie wir uns online authentifizieren: sie sind phishing‑resistent, bequem und basieren auf standardisierten FIDO/WebAuthn‑Mechanismen. Gleichzeitig bringt genau diese Herkunft aus dem WebAuthn‑Modell eine Einschränkung mit sich, die viele Entwickler und Admins vor Kopfzerbrechen stellt: Passkeys sind origin‑gebunden — sie funktionieren grundsätzlich nur auf der Domain (plus Scheme/Port), auf der sie registriert wurden. In diesem Artikel erkläre ich, wie ich mit Bitwarden‑basierten Setups arbeite, um Passkeys für mehrere Domains sicher und praktikabel zu verteilen — inklusive konkreter Vorgehensweisen, Vor‑ und Nachteilen sowie sicherheitsrelevanter Tipps.
Warum mehrere Domains ein Problem sind
Kurz zusammengefasst: ein Passkey (WebAuthn‑Credential) ist an einen "Relying Party Identifier" (rpId) gebunden. Bei klassischen Web‑Anwendungen ist das meistens die Domain (z. B. example.com). Wenn du denselben Passkey auf beispiel.de und beispiel.com verwenden willst, funktioniert das nicht automatisch — der Browser bzw. der Authenticator akzeptiert die rpId nicht, sofern die Credentials nicht explizit für beide Domains angelegt wurden.
Für Betreiber mit mehreren Marken, Multi‑Tenant‑Setups oder getrennten Frontends bedeutet das: Du musst dir aktiv Gedanken zur Architektur machen, damit Nutzer nicht bei jeder Domain separate Registrierungen durchführen müssen oder gar in unsichere Workarounds gedrängt werden.
Strategien, die ich empfehle
- Mehrfache Registrierung (einfach, zuverlässig): Nutzer registrieren ihren Passkey einmal pro Domain. Keine Architekturänderungen, funktioniert in allen Browsern/Authenticators, aber Aufwand für Nutzende steigt.
- Zentrales Authentifizierungs‑Domain / Single Sign‑On (empfohlen): Alle Domains delegieren Authentifizierung an eine zentrale IdP‑Domain (z. B. auth.example.com) via OIDC/SAML. Passkeys werden am IdP registriert — alle Services vertrauen dem IdP. Skalierbar und sicher, erfordert Identity‑Infrastruktur.
- Hardware‑Authenticators (YubiKey etc.): Physische Security Keys lassen sich mehrfach registrieren — praktisch für Nutzer, die den gleichen Key auf vielen Domains verwenden wollen. Achtung: Registrierung bleibt pro Domain erforderlich, aber das Handling ist konsistent und sicher.
- Backup‑ und Recovery‑Strategien mit Bitwarden: Bitwarden kann Metadaten, Registrierungshinweise, Backup‑Codes oder Passphrase‑Informationen sicher speichern. Ich empfehle Bitwarden nicht als Ersatz für den privaten Schlüssel eines Passkeys, sondern als sicheren Ort für ergänzende Informationen und Wiederherstellungsoptionen.
Praktische Schritt‑für‑Schritt‑Vorgehensweise mit Bitwarden
Ich beschreibe den Flow, den ich in Projekten nutze — er kombiniert SSO/IdP‑Ansatz mit Bitwarden für Dokumentation, Recovery‑Infos und Team‑Sharing.
Wenn möglich, richte eine zentrale Authentifizierungsdomain ein (z. B. auth.deinefirma.tld). Nutze Keycloak, Auth0, Azure AD oder ein anderes IdP, das WebAuthn/Passkeys nativ unterstützt. Registriere diese Domain als einzige Stelle, wo Passkeys erzeugt und gehostet werden.
Konfiguriere deine Services (app1.de, app2.de) so, dass sie OIDC/SAML‑Flows gegen den IdP ausführen. Nutzer sehen beim Login einen konsistenten Passkey‑Prompt, registrieren nur einmal am IdP und können sich bei allen Diensten anmelden.
Lege in Bitwarden strukturierte Items an:
- Item "Passkey‑Onboarding" mit Schritt‑für‑Schritt‑Anweisungen, URLs zur IdP‑Domain und Screenshots.
- Item "Recovery" mit Authenticator‑Backup‑Schritten, Backup‑Codes und Hinweis auf Hardware‑Token‑Aufbewahrung (als Attachments verschlüsselt).
- Teams/Collections: Für Organisationskonten lege geteilte Collections mit den relevanten Prozessdokumenten an, Rechte beschränken auf notwendige Personen.
Empfehle Nutzern, einen Hardware‑Key (z. B. YubiKey, SoloKey) als primären Authenticator zu registrieren. Vorteile: Multiplattform, langlebig, schneller Transfer zwischen Geräten. Dokumentiere Seriennummern und Ausgabedatum in Bitwarden (verschlüsselt), nicht jedoch private Schlüssel.
Für Partnerdomains, die du nicht zentral betreibst, bietest du einen leicht zugänglichen Onboarding‑Workflow an: kurze Registrierung auf der betreffenden Domain oder Redirect zur IdP‑Domain. Nutze Bitwarden‑Vorlagen, die du den Partnern zur Verfügung stellst.
Sicherheitsregeln, die ich strikt befolge
- Kein Ablegen privater Schlüssel in Bitwarden: Bitwarden verschlüsselt stark — trotzdem speichere ich keine privaten WebAuthn‑Schlüssel. Stattdessen speichere ich Wiederherstellungshinweise, Backup‑Codes oder Schritte zur Re‑Registrierung.
- Least Privilege bei geteilten Collections: Teams erhalten nur Zugriff auf das, was sie brauchen. Admin‑Sammlungen sind gesondert.
- Hardware‑Keys als Standard für Administratoren: Für kritische Konten zwinge ich 2FA mit Hardware‑Keys per Policy.
- Regelmäßiges Auditing: Ich prüfe, wer Zugriff auf welche Bitwarden‑Items hat, und rotiere Recovery‑Codes alle 6–12 Monate.
- Logging und Monitoring am IdP: Anmeldeversuche, neue Registrierungen und Anomalien werden zentral geloggt und überwacht.
Alternativen und ihre Vor‑/Nachteile
| Ansatz | Vorteile | Nachteile |
|---|---|---|
| Mehrfache Registrierung | Einfach, keine Infrastrukturänderung | Umständlich für Nutzer, schlechtere UX |
| Zentrales IdP (SSO) | Skalierbar, gute UX, zentralisiertes Security‑Management | Komplexe Einrichtung, Single Point of Failure (muss gehärtet werden) |
| Hardware‑Keys | Sehr sicher, plattformunabhängig | Kosten für Mitarbeiter, Verwaltung von verlorenen Keys |
| Bitwarden als Passkey‑Speicher | Bequem für Dokumentation und Sharing | Nicht geeignet für private Schlüssel; kein Ersatz für Authenticator |
Typische Fragen, die ich immer wieder beantworte
Kann Bitwarden Passkeys direkt hosten und für mehrere Domains verteilen?
Bitwarden ist in erster Linie ein Passwortmanager und Secrets‑Store. Er eignet sich hervorragend zum Speichern von Anleitungen, Backup‑Codes, und Metadaten, aber nicht als Host für WebAuthn‑Private‑Keys. Wenn Bitwarden native Passkey‑Features anbietet (z. B. Item‑Typen für Passkeys), nutze ich diese nur als Metadaten/Verweise, nicht als primäre Geheimnis‑Quelle.
Müssen Nutzer für jede Domain einen neuen Passkey erstellen?
Ja, wenn keine zentrale IdP‑Lösung existiert. Registrierung pro Domain ist das sicherste und breit unterstützte Vorgehen.
Wie handhabe ich verlorene Geräte?
Backup‑Codes, ein zweiter Hardware‑Key und klar dokumentierte Re‑Onboarding‑Prozesse (in Bitwarden) sind essentiell. Für Admins empfehle ich einen getrennten Krisen‑Account mit Hardware‑Key und separatem Recovery‑Workflow.
Praktische Checkliste vor dem Rollout
- IdP‑Strategie definieren: Ja/Nein?
- Bitwarden‑Collections und Zugriffsrollen anlegen
- Hardware‑Key‑Policy erstellen (Ausgabe, Ersatz, Revocation)
- Onboarding‑Dokumente in Bitwarden hinterlegen
- Monitoring und Alarmierung für IdP‑Anmeldungen aktivieren
- Regelmäßige Reviews und Rotationstermine planen
Passkeys sind eine hervorragende Basis für sicheres, modernes Authentication‑Design — die Herausforderung bei mehreren Domains ist weniger technisch als architektonisch und organisatorisch. In meinen Projekten zahlt sich die Investition in eine zentrale Authentifizierungsarchitektur und klare Prozesse (dokumentiert und sicher geteilt in Bitwarden) langfristig aus: bessere UX für Nutzer, weniger Supportaufwand und eine deutlich höhere Sicherheit.