Wie passwortlose Anmeldung unter der Haube funktioniert
Sie klicken auf „Anmelden”, Ihr Smartphone fragt nach einem Fingerabdruck, und Sie sind authentifiziert. Kein Passwort eingegeben, kein Code aus einer E-Mail kopiert. Wenn Sie bereits Authentifizierungsabläufe implementiert haben, fühlt sich das wahrscheinlich wie Magie an – oder schlimmer noch, wie eine Black Box, die Sie integrieren sollen, ohne sie zu verstehen.
Dieser Artikel erklärt, wie Passkeys und WebAuthn tatsächlich unter den Browser-APIs funktionieren. Sie werden den Authentifizierungsablauf, die beteiligten kryptografischen Primitive und die Sicherheitseigenschaften verstehen, die FIDO2-basierte passwortlose Authentifizierung grundlegend von älteren Ansätzen wie Magic Links oder OTPs unterscheiden.
Wichtigste Erkenntnisse
- Passkeys verwenden Public-Key-Kryptografie, bei der der private Schlüssel niemals Ihr Gerät verlässt, wodurch gemeinsam genutzte Geheimnisse eliminiert werden, die Angreifer abfangen oder stehlen können.
- WebAuthn-Authentifizierung umfasst vier Parteien: Ihr Frontend, die Browser-API, den Authenticator (Geräte-Keychain oder Hardware-Schlüssel) und Ihren Server.
- Origin-Binding bietet kryptografische Phishing-Resistenz – Credentials sind an bestimmte Domains gebunden und funktionieren nicht auf nachgeahmten Websites.
- Conditional UI ermöglicht es, dass Passkey-Aufforderungen in Autofill-Vorschlägen erscheinen und so nahtlose Authentifizierungserlebnisse schaffen.
Warum Passkeys frühere „passwortlose” Methoden ersetzt haben
Magic Links und Einmalpasswörter entfernten das Passwortfeld aus Anmeldeformularen, eliminierten jedoch keine gemeinsam genutzten Geheimnisse. Ein Magic Link ist immer noch ein Bearer-Token, der per E-Mail übertragen wird – abfangbar, wiederverwendbar und anfällig für Phishing, wenn Benutzer auf Links in gefälschten Domains klicken. Per SMS gesendete OTPs sind anfällig für SIM-Swapping-Angriffe.
Passkeys lösen dies anders. Sie verwenden Public-Key-Kryptografie, bei der das Geheimnis (Ihr privater Schlüssel) niemals Ihr Gerät verlässt und niemals über das Netzwerk übertragen wird. Der Server speichert nur Ihren öffentlichen Schlüssel, der für Angreifer selbst bei einem Datenbank-Breach nutzlos ist.
Das ist die zentrale Erkenntnis hinter FIDO2 und WebAuthn: Authentifizierung erfolgt durch kryptografischen Besitznachweis, nicht durch Übertragung von Geheimnissen.
Der WebAuthn-Authentifizierungsablauf
Wenn sich ein Benutzer mit einem Passkey authentifiziert, interagieren typischerweise vier Komponenten: Ihr Frontend-Code, die WebAuthn-API des Browsers, der Authenticator (oft die OS-Keychain, ein Smartphone oder ein Hardware-Sicherheitsschlüssel) und Ihr Server.
Registrierung: Erstellen des Credentials
Während der Registrierung generiert Ihr Server eine Challenge – eine zufällige Byte-Sequenz – und sendet sie zusammen mit Ihrer Relying Party ID (typischerweise Ihre Domain) an den Browser. Ihr Frontend ruft navigator.credentials.create() mit diesen Parametern auf.
Der Browser übergibt diese Anfrage via CTAP (Client to Authenticator Protocol) an den Authenticator. Der Authenticator generiert ein neues Schlüsselpaar, speichert den privaten Schlüssel sicher und gibt den öffentlichen Schlüssel zusammen mit einer signierten Attestierung zurück.
Ihr Server empfängt und speichert den öffentlichen Schlüssel, die Credential-ID und Metadaten wie einen Signaturzähler. Kein Passwort-Hash, kein gemeinsam genutztes Geheimnis – nur ein öffentlicher Schlüssel, der auf Ihre Domain beschränkt ist.
Authentifizierung: Besitznachweis
Wenn der Benutzer zurückkehrt, generiert Ihr Server eine neue Challenge. Ihr Frontend ruft navigator.credentials.get() auf, und der Browser fordert den Authenticator auf.
Der Authenticator findet das Credential, das zu Ihrer RP-ID passt, fordert Benutzerverifizierung (biometrisch, PIN oder Präsenz), und signiert dann die Challenge mit dem privaten Schlüssel. Diese Signatur kehrt zusammen mit Authenticator-Daten zu Ihrem Server zurück.
Ihr Server verifiziert die Signatur gegen den gespeicherten öffentlichen Schlüssel. Wenn sie übereinstimmt, hat der Benutzer bewiesen, dass er den privaten Schlüssel besitzt, ohne ihn jemals zu übertragen.
Origin-Binding: Der Phishing-Resistenz-Mechanismus
Hier ist, was Passkeys wirklich phishing-resistent macht, anstatt nur „schwerer zu phishen”. Der Authenticator bindet Credentials kryptografisch an den Origin der Relying Party.
Beim Signieren der Challenge fügt der Authenticator den Relying-Party-ID-Hash (abgeleitet von Ihrer Domain) in die signierten Daten ein. Wenn ein Angreifer eine nachgeahmte Website unter g00gle.com erstellt, funktioniert das Credential für google.com einfach nicht – die Origins stimmen nicht überein, und der Authenticator erzeugt keine gültige Signatur.
Dies ist keine UI-Warnung, die Benutzer wegklicken können. Es wird kryptografisch auf Protokollebene durchgesetzt.
Discover how at OpenReplay.com.
Synchronisierte vs. gerätegebundene Passkeys
Moderne Passkeys werden typischerweise über OS-Keychains geräteübergreifend synchronisiert – Apples iCloud Keychain, Google Password Manager oder Drittanbieter-Manager wie 1Password. Dies verbessert die Benutzerfreundlichkeit erheblich, da Benutzer beim Gerätewechsel nicht den Zugang verlieren.
Gerätegebundene Passkeys (wie Hardware-Sicherheitsschlüssel) bieten stärkere Garantien – der private Schlüssel existiert nachweislich auf genau einem Gerät. Für die meisten Webanwendungen bieten synchronisierte Passkeys ausreichende Sicherheit bei besserer UX. Ihr Bedrohungsmodell bestimmt, was wichtiger ist.
Moderne UX-Muster: Conditional UI
Sie haben wahrscheinlich schon gesehen, wie Passkey-Aufforderungen in den Autofill-Vorschlägen des Benutzernamenfelds erscheinen. Das ist Conditional UI – der Browser bietet proaktiv verfügbare Passkeys an, bevor der Benutzer explizit eine passwortlose Anmeldung anfordert.
Implementieren Sie dies, indem Sie navigator.credentials.get() mit mediation: 'conditional' aufrufen und autocomplete="username" zu Ihrem Eingabefeld hinzufügen.
Der Browser übernimmt die Erkennung und Präsentation.
Viele Anwendungen nutzen jetzt Conditional UI, um bestehende Benutzer zu aktualisieren: Nach einer erfolgreichen Passwort-Anmeldung werden Benutzer aufgefordert, einen Passkey für zukünftige Sitzungen zu registrieren.
Sicherheitseigenschaften und Vertrauensgrenzen
Passkeys reduzieren die Angriffsfläche dramatisch, aber sie sind keine Magie. Die Sicherheit des privaten Schlüssels hängt von der Implementierung des Authenticators ab – typischerweise die Secure Enclave oder das TPM des Geräts. Wenn das Gerät selbst auf Hardware-Ebene kompromittiert ist, sind alle Wetten ungültig.
Account-Wiederherstellung bleibt eine Design-Herausforderung. Wenn Benutzer alle ihre Geräte verlieren, benötigen Sie Fallback-Mechanismen, die nicht die Schwachstellen wieder einführen, die Passkeys eliminiert haben.
WebAuthn entwickelt sich weiter – Level 3 ist die aktuelle Generation der Spezifikation – mit laufenden Arbeiten an geräteübergreifender Authentifizierung und Enterprise-Attestierung. Die hier behandelten Grundlagen bleiben stabil.
Fazit
Passkeys verschieben die Authentifizierung von „verifiziere, dass der Benutzer ein Geheimnis kennt” zu „verifiziere, dass der Benutzer einen Schlüssel besitzt”. Dies ändert Ihr mentales Modell: Sie prüfen nicht Passwörter gegen Hashes, sondern verifizieren kryptografische Signaturen gegen öffentliche Schlüssel.
Für Frontend-Entwickler ist die praktische Implikation unkompliziert: Lernen Sie die Registrierungs- und Authentifizierungszeremonien der WebAuthn-API, implementieren Sie Conditional UI für nahtlose Erkennung und entwerfen Sie Upgrade-Pfade, die Benutzer schrittweise von Passwörtern zu Passkeys führen.
FAQs
Account-Wiederherstellung wird kritisch, wenn Benutzer alle Geräte verlieren. Gängige Ansätze umfassen Backup-Recovery-Codes, die während der Registrierung generiert werden, sekundäre Authentifizierungsmethoden wie verifizierte E-Mail oder Identitätsverifizierungsprozesse. Die Herausforderung besteht darin, Fallbacks zu entwerfen, die nicht die Schwachstellen wieder einführen, die Passkeys eliminiert haben, wie phishbare Magic Links oder abfangbare SMS-Codes.
Ja, Passkeys sind für plattformübergreifende Kompatibilität konzipiert. Synchronisierte Passkeys, die in Plattform-Keychains wie iCloud Keychain oder Google Password Manager gespeichert sind, funktionieren geräteübergreifend innerhalb dieses Ökosystems. Für ökosystemübergreifende Authentifizierung können Benutzer QR-Codes scannen, um sich mit einem auf einem anderen Gerät gespeicherten Passkey zu authentifizieren, wobei das FIDO2-Hybrid-Transport-Protokoll genutzt wird.
Jedes Passkey-Credential ist einzigartig und an ein bestimmtes Benutzerkonto und eine Relying Party gebunden. Wenn mehrere Passkeys für dieselbe Domain existieren, präsentiert der Browser oder Authenticator eine Auswahlschnittstelle, die es Benutzern ermöglicht, zu wählen, welches Credential verwendet werden soll. Die serverseitig gespeicherte Credential-ID ordnet jeden Passkey seinem entsprechenden Benutzerkonto zu.
Passkeys widerstehen Man-in-the-Middle-Angriffen durch Origin-Binding. Der Authenticator fügt den exakten Origin in die signierte Authentifizierungsantwort ein. Wenn ein Angreifer den Authentifizierungsversuch über einen Proxy abfängt und weiterleitet, führt die Origin-Diskrepanz dazu, dass die Signaturverifizierung fehlschlägt. Die kryptografische Bindung macht Echtzeit-Phishing-Angriffe wirkungslos.
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
