Passw\u00f6rter sind das schw\u00e4chste Glied der meisten Web-Anwendungen. Phishing, Credential Stuffing und wiederverwendete Logins verursachen den Gro\u00dfteil aller Konto\u00fcbernahmen. Passkeys l\u00f6sen dieses Problem an der Wurzel, weil sie auf Public-Key-Kryptografie statt auf geteilten Geheimnissen beruhen. Laut FIDO Alliance besitzen 2025 bereits 69 Prozent der Verbraucher mindestens einen Passkey, und 48 Prozent der 100 gr\u00f6\u00dften Websites unterst\u00fctzen die Anmeldung ohne Passwort. Dieser Leitfaden zeigt Ihnen Schritt f\u00fcr Schritt, wie Sie Passkeys in Node.js mit dem WebAuthn-Standard implementieren, inklusive eines vollst\u00e4ndigen, lauff\u00e4higen Projekts.<\/p>\n\n\n\n
Wir bauen ein komplettes passwortloses Login-System: ein Express-Backend mit der Bibliothek Ein Passkey ist ein kryptografisches Schl\u00fcsselpaar, das ein Ger\u00e4t oder ein Passwortmanager f\u00fcr eine bestimmte Website erzeugt. Der private Schl\u00fcssel verl\u00e4sst das Ger\u00e4t nie. Der \u00f6ffentliche Schl\u00fcssel wandert zum Server und wird dort gespeichert. Bei der Anmeldung beweist das Ger\u00e4t den Besitz des privaten Schl\u00fcssels durch eine digitale Signatur, ohne das Geheimnis selbst zu \u00fcbertragen. Genau dieser Mechanismus macht Passkeys gegen Phishing immun, denn es gibt kein Passwort, das ein Angreifer abgreifen k\u00f6nnte.<\/p>\n\n\n\n Die technische Grundlage bilden zwei Standards. WebAuthn ist die Browser-API, die das W3C zusammen mit der FIDO Alliance definiert hat. Sie steuert die Kommunikation zwischen Webseite und Authenticator. CTAP2 (Client to Authenticator Protocol) regelt, wie der Browser mit externen Authenticatoren wie einem YubiKey oder dem Smartphone spricht. Zusammen ergeben WebAuthn und CTAP2 das FIDO2-Framework. Wenn dieser Artikel von WebAuthn in Node.js spricht, meint er die serverseitige H\u00e4lfte dieses Protokolls: das Erzeugen von Challenges und das Verifizieren von Signaturen.<\/p>\n\n\n\n Der aktuelle Stand der Standardisierung ist eindeutig: WebAuthn Level 2 ist die offizielle W3C-Empfehlung (W3C Web Authentication Level 2<\/a>), w\u00e4hrend Level 3<\/a> den Standard um Funktionen wie verbesserte Conditional UI erweitert und sich in fortgeschrittener Standardisierung befindet. Alle modernen Browser (Chrome, Safari, Firefox, Edge) und Betriebssysteme unterst\u00fctzen WebAuthn produktiv. Eine gepflegte Referenz f\u00fcr Entwickler ist passkeys.dev<\/a>, ein Gemeinschaftsprojekt der FIDO Alliance.<\/p>\n\n\n\n WebAuthn kennt genau zwei Abl\u00e4ufe, in der Spezifikation Ceremonies genannt. Die Registrierung (Attestation) erzeugt ein neues Schl\u00fcsselpaar und meldet den \u00f6ffentlichen Schl\u00fcssel beim Server an. Die Authentifizierung (Assertion) nutzt ein bestehendes Schl\u00fcsselpaar, um eine Anmeldung zu signieren. Beide folgen demselben Muster: Der Server erzeugt eine zuf\u00e4llige Challenge, der Browser leitet sie an den Authenticator weiter, das Ger\u00e4t signiert sie nach einer Nutzerbest\u00e4tigung, und der Server pr\u00fcft die Antwort. Diese vier Phasen werden Sie in Node.js exakt nachbauen.<\/p>\n\n\n\n Der entscheidende Schutz liegt in der Origin-Bindung. Ein Passkey ist kryptografisch an die Domain gebunden, f\u00fcr die er erstellt wurde. Versucht eine Phishing-Seite unter einer falschen Domain, eine Anmeldung auszul\u00f6sen, verweigert der Browser die Signatur, weil die Origin nicht \u00fcbereinstimmt. Selbst ein perfekt nachgebautes Login-Formular l\u00e4uft ins Leere. Diese Eigenschaft pr\u00fcft Ihr Server sp\u00e4ter \u00fcber die Parameter Technisch besteht die Antwort des Authenticators bei der Anmeldung aus zwei Teilen: den Die Verbreitung von Passkeys hat 2025 einen Wendepunkt erreicht. Gro\u00dfe Plattformen melden nicht nur h\u00f6here Sicherheit, sondern auch bessere Conversion, weil sich Nutzer schneller und seltener fehlerhaft anmelden. Die folgende Tabelle fasst die belastbaren Kennzahlen aus offiziellen Quellen zusammen.<\/p>\n\n\n\n@simplewebauthn\/server<\/code>, eine SQLite-Datenbank f\u00fcr Nutzer und Credentials sowie ein schlankes Frontend mit @simplewebauthn\/browser<\/code>. Am Ende registrieren und authentifizieren sich Nutzer per Fingerabdruck, Gesichtserkennung oder Hardware-Schl\u00fcssel, ganz ohne Passwort. Stand: 23. Juni 2026. Planen Sie rund 40 Minuten f\u00fcr die Umsetzung ein.<\/p>\n\n\n\nWas sind Passkeys? WebAuthn und FIDO2 in der Praxis<\/h2>\n\n\n\n
Registrierung und Authentifizierung: die zwei Ceremonies<\/h3>\n\n\n\n
Warum Passkeys phishing-resistent sind<\/h3>\n\n\n\n
expectedOrigin<\/code> und expectedRPID<\/code>. Ein gestohlener \u00f6ffentlicher Schl\u00fcssel n\u00fctzt einem Angreifer ohne das physische Ger\u00e4t und die biometrische Freigabe nichts.<\/p>\n\n\n\nauthenticatorData<\/code> und dem clientDataJSON<\/code>, das die Challenge und die Origin enth\u00e4lt. Der Authenticator signiert die Verkettung dieser Daten mit dem privaten Schl\u00fcssel. Ihr Server berechnet denselben Wert erneut und pr\u00fcft die Signatur mit dem gespeicherten \u00f6ffentlichen Schl\u00fcssel. Stimmt alles, ist bewiesen, dass dieselbe Hardware antwortet, die sich urspr\u00fcnglich registriert hat, und dass die Anmeldung f\u00fcr genau diese Domain bestimmt war. Diese Pr\u00fcfung erledigt verifyAuthenticationResponse<\/code> f\u00fcr Sie, doch zu wissen, was darunter passiert, hilft bei der Fehlersuche enorm.<\/p>\n\n\n\nPasskeys vs. Passw\u00f6rter: die Zahlen f\u00fcr 2026<\/h2>\n\n\n\n