Passkey für Anmeldungen ohne Passwort erstellen

Passkeys machen Nutzerkonten sicherer, einfacher und benutzerfreundlicher.

Eiji Kitamura

Veröffentlicht: 12. Oktober 2022, zuletzt aktualisiert: 9. April 2026

Passkeys bieten mehr Sicherheit, vereinfachen die Anmeldung und ersetzen Passwörter. Im Gegensatz zu herkömmlichen Passwörtern, die Nutzer sich merken und manuell eingeben müssen, werden bei Passkeys die Mechanismen der Displaysperre des Geräts wie biometrische Daten oder PINs verwendet. Dadurch werden Phishing-Risiken und Anmeldediebstahl verringert.

Passkeys werden über Passkey-Anbieter wie den Google Passwortmanager und den iCloud-Schlüsselbund geräteübergreifend synchronisiert.

Ein Passkey muss erstellt werden, wobei der private Schlüssel zusammen mit den erforderlichen Metadaten sicher beim Passkey-Anbieter gespeichert wird. Der öffentliche Schlüssel wird zur Authentifizierung auf Ihrem Server gespeichert. Der private Schlüssel gibt nach der Nutzerbestätigung in der gültigen Domain eine Signatur aus, wodurch Passkeys vor Phishing geschützt sind. Der öffentliche Schlüssel verifiziert die Signatur, ohne vertrauliche Anmeldedaten zu speichern. Dadurch sind Passkeys vor Anmeldedatendiebstahl geschützt.

So funktioniert das Erstellen eines Passkeys

Bevor sich ein Nutzer mit einem Passkey anmelden kann, müssen Sie den Passkey erstellen, ihn einem Nutzerkonto zuordnen und den öffentlichen Schlüssel auf Ihrem Server speichern.

Sie können Nutzer in den folgenden Situationen bitten, einen Passkey zu erstellen:

• Während oder nach der Registrierung.
• Nach der Anmeldung.
• Nachdem Sie sich mit einem Passkey von einem anderen Gerät angemeldet haben (d. h. das authenticatorAttachment ist cross-platform).
• Auf einer speziellen Seite, auf der Nutzer ihre Passkeys verwalten können.

Zum Erstellen eines Passkeys verwenden Sie die WebAuthn API.

Der Ablauf der Passkey-Registrierung umfasst vier Komponenten:

• Backend: Hier werden Nutzerkontodetails gespeichert, einschließlich des öffentlichen Schlüssels.
• Frontend: Kommuniziert mit dem Browser und ruft die erforderlichen Daten aus dem Backend ab.
• Browser: Führt Ihr JavaScript aus und interagiert mit der WebAuthn API.
• Passkey-Anbieter: Erstellt und speichert den Passkey. Das ist in der Regel ein Passwortmanager wie der Google Passwortmanager oder ein Sicherheitsschlüssel.

Bevor Sie einen Passkey erstellen, muss das System die folgenden Voraussetzungen erfüllen:

• Das Nutzerkonto wird innerhalb eines angemessen kurzen Zeitraums über eine sichere Methode bestätigt, z. B. per E‑Mail, Telefon oder Identitätsföderation.

• Das Frontend und das Backend können sicher kommunizieren, um Anmeldedaten auszutauschen.

• Der Browser unterstützt WebAuthn und die Erstellung von Passkeys.

In den folgenden Abschnitten erfahren Sie, wie Sie die meisten davon prüfen können.

Wenn das System diese Bedingungen erfüllt, wird ein Passkey so erstellt:

1. Das System löst die Erstellung des Passkeys aus, wenn der Nutzer die Aktion initiiert, z. B. indem er auf der Seite zur Passkey-Verwaltung oder nach Abschluss der Registrierung auf die Schaltfläche „Passkey erstellen“ klickt.
2. Das Frontend fordert die erforderlichen Anmeldedaten vom Backend an, einschließlich Nutzerinformationen, einer Challenge und Anmeldedaten-IDs, um Duplikate zu vermeiden.
3. Das Frontend ruft navigator.credentials.create() auf, um den Passkey-Anbieter des Geräts aufzufordern, einen Passkey anhand der Informationen aus dem Backend zu generieren. Beachten Sie, dass dieser Aufruf ein Promise zurückgibt.
4. Das Gerät des Nutzers authentifiziert den Nutzer mit einem biometrischen Verfahren, einer PIN oder einem Muster, um den Passkey zu erstellen.
5. Der Passkey-Anbieter erstellt einen Passkey und gibt ein Anmeldedatenobjekt mit einem öffentlichen Schlüssel an das Frontend zurück, wodurch das Promise aufgelöst wird.
6. Das Frontend sendet die generierte Anmeldedaten für den öffentlichen Schlüssel an das Backend.
7. Das Backend speichert den öffentlichen Schlüssel und andere wichtige Daten für die zukünftige Authentifizierung.
8. Das Backend benachrichtigt den Nutzer (z. B. per E-Mail), um die Erstellung des Passkeys zu bestätigen und potenziellen unbefugten Zugriff zu erkennen.

Dieser Prozess sorgt für eine sichere und nahtlose Passkey-Registrierung für Nutzer.

Kompatibilitäten

Die meisten Browser unterstützen WebAuthn, es gibt jedoch einige kleinere Lücken. Details zur Browser- und Betriebssystemkompatibilität finden Sie unter passkeys.dev.

Neuen Passkey erstellen

So sollte das Frontend vorgehen, um einen neuen Passkey zu erstellen:

1. Kompatibilität prüfen
2. Informationen aus dem Backend abrufen:
3. WebAuth-API aufrufen, um einen Passkey zu erstellen
4. Senden Sie den zurückgegebenen öffentlichen Schlüssel an das Backend.
5. Anmeldedaten speichern

In den folgenden Abschnitten wird beschrieben, wie Sie vorgehen müssen.

Auf Kompatibilität prüfen

Bevor eine Schaltfläche zum Erstellen eines neuen Passkeys angezeigt wird, sollte das Frontend prüfen, ob:

• Der Browser unterstützt WebAuthn mit PublicKeyCredential.

• Der Browser unterstützt die Erkennung von Funktionen mit PublicKeyCredential.getClientCapabilities().

• Der Browser unterstützt die bedingte WebAuthn-Benutzeroberfläche mit conditionalGet.

• Das Gerät unterstützt einen Plattformauthentifikator (Passkey kann erstellt und auf dem Gerät authentifiziert werden) mit passkeyPlatformAuthenticator.

Das folgende Code-Snippet zeigt, wie Sie vor dem Anzeigen der passkeybezogenen Optionen die Kompatibilität prüfen können.

if (window.PublicKeyCredential && PublicKeyCredential.getClientCapabilities) {
  const capabilities = await PublicKeyCredential.getClientCapabilities();
  if (capabilities.conditionalGet === true &&
      capabilities.passkeyPlatformAuthenticator === true) {
    // The browser supports passkeys and the conditional UI.
  }
}

In diesem Beispiel sollte die Schaltfläche Neuen Passkey erstellen nur angezeigt werden, wenn alle Bedingungen erfüllt sind.

Informationen aus dem Backend abrufen

Wenn der Nutzer auf die Schaltfläche klickt, rufen Sie die erforderlichen Informationen aus dem Backend ab, um navigator.credentials.create() aufzurufen.

Das folgende Code-Snippet zeigt ein JSON-Objekt mit den erforderlichen Informationen für den Aufruf von navigator.credentials.create():

// Example `PublicKeyCredentialCreationOptions` contents
{
  challenge: *****,
  rp: {
    name: "Example",
    id: "example.com",
  },
  user: {
    id: *****,
    name: "john78",
    displayName: "John",
  },
  pubKeyCredParams: [{
    alg: -7, type: "public-key"
  },{
    alg: -257, type: "public-key"
  }],
  excludeCredentials: [{
    id: *****,
    type: 'public-key',
    transports: ['internal'],
  }],
  authenticatorSelection: {
    authenticatorAttachment: "platform",
    requireResidentKey: true,
  }
}

Die Schlüssel/Wert-Paare im Objekt enthalten die folgenden Informationen:

• challenge: Eine vom Server generierte Challenge in ArrayBuffer für diese Registrierung.
• rp.id: Eine RP-ID (Relying Party ID), eine Domain und eine Website können entweder ihre Domain oder ein registrierbares Suffix angeben. Wenn der Ursprung eines RP beispielsweise https://login.example.com:1337 ist, kann die RP-ID entweder login.example.com oder example.com sein. Wenn die RP-ID als example.com angegeben ist, kann sich der Nutzer auf login.example.com oder auf einer beliebigen Subdomain von example.com authentifizieren. Weitere Informationen finden Sie unter Passkeys auf Ihren Websites mit Anfragen zu ähnlichen Ursprüngen wiederverwenden.
• rp.name: Der Name der vertrauenden Seite. Diese Funktion ist in WebAuthn L3 veraltet, wird aber aus Kompatibilitätsgründen weiterhin unterstützt.
• user.id: Eine eindeutige Nutzer-ID in ArrayBuffer, die beim Erstellen des Kontos generiert wird. Er sollte dauerhaft sein, im Gegensatz zu einem Nutzernamen, der bearbeitet werden kann. Die Nutzer-ID identifiziert ein Konto, darf aber keine personenidentifizierbaren Informationen enthalten. Sie haben wahrscheinlich bereits eine Nutzer-ID in Ihrem System. Falls erforderlich, erstellen Sie eine speziell für Passkeys, damit sie keine personenbezogenen Daten enthält.
• user.name: Eine eindeutige Kennung für das Konto, die der Nutzer kennt, z. B. seine E-Mail-Adresse oder sein Nutzername. Diese wird in der Kontoauswahl angezeigt.
• user.displayName: Ein erforderlicher, nutzerfreundlicherer Name für das Konto. Er muss nicht eindeutig sein und kann der vom Nutzer gewählte Name sein. Wenn Ihre Website keinen geeigneten Wert für dieses Feld hat, übergeben Sie einen leeren String. Je nach Browser wird diese Information möglicherweise in der Kontoauswahl angezeigt.
• pubKeyCredParams: Gibt die von der RP (relying party) unterstützten Algorithmen für öffentliche Schlüssel an. Wir empfehlen, den Wert auf [{alg: -7, type: "public-key"},{alg: -257, type: "public-key"}] festzulegen. Dies gibt die Unterstützung für ECDSA mit P-256 und RSA PKCS#1 an. Durch die Unterstützung dieser beiden Verfahren wird eine vollständige Abdeckung erreicht.
• excludeCredentials: Eine Liste der bereits registrierten Anmeldedaten-IDs. Verhindert die doppelte Registrierung desselben Geräts durch Bereitstellung einer Liste bereits registrierter Anmeldedaten-IDs. Das Element transports sollte, sofern angegeben, das Ergebnis des Aufrufs von getTransports() während der Registrierung der einzelnen Anmeldedaten enthalten.
• authenticatorSelection.authenticatorAttachment: Legen Sie diesen Wert zusammen mit hint: ['client-device'] auf "platform" fest, wenn die Erstellung dieses Passkeys ein Upgrade von einem Passwort ist, z. B. im Rahmen einer Werbeaktion nach der Anmeldung. "platform" gibt an, dass der RP einen Plattformauthentifikator (einen in das Plattformgerät eingebetteten Authentifikator) benötigt, bei dem z. B. nicht aufgefordert wird, einen USB-Sicherheitsschlüssel einzufügen. Der Nutzer hat eine einfachere Möglichkeit, einen Passkey zu erstellen.
• authenticatorSelection.requireResidentKey: Legen Sie einen booleschen true fest. Ein auffindbarer Anmeldedatensatz (resident key) speichert Nutzerinformationen im Passkey und ermöglicht es Nutzern, das Konto bei der Authentifizierung auszuwählen.

• authenticatorSelection.userVerification: Gibt an, ob die Nutzerbestätigung über die Displaysperre des Geräts "required", "preferred" oder "discouraged" ist. Der Standardwert ist "preferred". Das bedeutet, dass der Authenticator die Nutzerbestätigung möglicherweise überspringt. Legen Sie dafür "preferred" fest oder lassen Sie das Attribut weg.

Wir empfehlen, das Objekt auf dem Server zu erstellen, den ArrayBuffer mit Base64URL zu codieren und ihn vom Frontend abzurufen. So können Sie die Nutzlast mit PublicKeyCredential.parseCreationOptionsFromJSON() decodieren und direkt an navigator.credentials.create() übergeben.

Das folgende Code-Snippet zeigt, wie Sie die Informationen abrufen und decodieren können, die zum Erstellen des Passkeys erforderlich sind.

// Fetch an encoded `PubicKeyCredentialCreationOptions` from the server.
const _options = await fetch('/webauthn/registerRequest');

// Deserialize and decode the `PublicKeyCredentialCreationOptions`.
const decoded_options = JSON.parse(_options);
const options = PublicKeyCredential.parseCreationOptionsFromJSON(decoded_options);
...

WebAuthn-API aufrufen, um einen Passkey zu erstellen

Rufen Sie navigator.credentials.create() auf, um einen neuen Passkey zu erstellen. Die API gibt ein Promise zurück und wartet auf die Nutzerinteraktion, indem ein modales Dialogfeld angezeigt wird.

// Invoke WebAuthn to create a passkey.
const credential = await navigator.credentials.create({
  publicKey: options
});

Zurückgegebenen Public-Key-Anmeldedaten an das Backend senden

Nachdem der Nutzer über die Displaysperre des Geräts bestätigt wurde, wird ein Passkey erstellt und das Promise wird aufgelöst. Dabei wird ein PublicKeyCredential-Objekt an das Frontend zurückgegeben.

Das Versprechen kann aus verschiedenen Gründen abgelehnt werden. Sie können diese Fehler beheben, indem Sie die name-Eigenschaft des Error-Objekts prüfen:

• InvalidStateError: Auf dem Gerät ist bereits ein Passkey vorhanden. Dem Nutzer wird kein Fehlerdialogfeld angezeigt. Die Website sollte dies nicht als Fehler behandeln. Der Nutzer wollte das lokale Gerät registrieren und das ist auch geschehen.
• NotAllowedError: Der Nutzer hat den Vorgang abgebrochen.
• AbortError: Der Vorgang wurde abgebrochen.
• Andere Ausnahmen: Ein unerwarteter Fehler ist aufgetreten. Der Browser zeigt dem Nutzer ein Fehlerdialogfeld an.

Das Objekt für Anmeldedaten mit öffentlichem Schlüssel enthält die folgenden Eigenschaften:

• id: Eine Base64URL-codierte ID des erstellten Passkeys. Anhand dieser ID kann der Browser bei der Authentifizierung feststellen, ob ein passendes Passkey auf dem Gerät vorhanden ist. Dieser Wert muss in der Datenbank im Backend gespeichert werden.
• rawId: Eine ArrayBuffer-Version der Anmeldedaten-ID.
• response.clientDataJSON: ArrayBuffer-codierte Clientdaten.
• response.attestationObject: Ein als ArrayBuffer codiertes Attestierungsobjekt. Sie enthält wichtige Informationen wie eine RP-ID, Flags und einen öffentlichen Schlüssel.
• authenticatorAttachment: Gibt "platform" zurück, wenn diese Anmeldedaten auf einem Gerät erstellt werden, das Passkeys unterstützt.
• type: Dieses Feld ist immer auf "public-key" gesetzt.

Codieren Sie das Objekt mit der Methode .toJSON(), serialisieren Sie es mit JSON.stringify() und senden Sie es dann an den Server.

...

// Encode and serialize the `PublicKeyCredential`.
const _result = credential.toJSON();
const result = JSON.stringify(_result);

// Encode and send the credential to the server for verification.  
const response = await fetch('/webauthn/registerResponse', {
  method: 'post',
  credentials: 'same-origin',
  body: result
});
...

Anmeldedaten speichern

Nachdem Sie die Anmeldedaten für den öffentlichen Schlüssel im Backend erhalten haben, empfehlen wir, eine serverseitige Bibliothek oder Lösung zu verwenden, anstatt eigenen Code zum Verarbeiten von Anmeldedaten für den öffentlichen Schlüssel zu schreiben.

Sie können die aus dem Anmeldedaten abgerufenen Informationen dann zur späteren Verwendung in der Datenbank speichern.

In der folgenden Liste finden Sie empfohlene Properties, die Sie speichern sollten:

• Anmeldedaten-ID: Die Anmeldedaten-ID, die mit den Anmeldedaten für den öffentlichen Schlüssel zurückgegeben wird.
• Name der Qualifikation: Der Name der Qualifikation. Benennen Sie ihn nach dem Passkey-Anbieter, von dem er erstellt wurde. Dieser kann anhand der AAGUID identifiziert werden.
• Nutzer-ID: Die Nutzer-ID, mit der der Passkey erstellt wurde.
• Öffentlicher Schlüssel: Der öffentliche Schlüssel, der mit dem Anmeldedatenpaar für den öffentlichen Schlüssel zurückgegeben wird. Dies ist erforderlich, um eine Passkey-Assertion zu bestätigen.
• Erstellungsdatum und ‑uhrzeit: Datum und Uhrzeit der Passkey-Erstellung. Dies ist nützlich, um den Passkey zu identifizieren.
• Datum und Uhrzeit der letzten Verwendung: Hier wird das letzte Datum und die letzte Uhrzeit aufgezeichnet, zu der sich der Nutzer mit dem Passkey angemeldet hat. So lässt sich feststellen, welchen Passkey der Nutzer verwendet hat (oder nicht verwendet hat).
• AAGUID: Eine eindeutige Kennung des Passkey-Anbieters.
• Flag für die Berechtigung zur Sicherung: „true“, wenn das Gerät für die Passkeysynchronisierung infrage kommt. Anhand dieser Informationen können Nutzer auf der Seite zur Passkey-Verwaltung synchronisierbare und gerätegebundene (nicht synchronisierbare) Passkeys erkennen.

Eine detailliertere Anleitung finden Sie unter Serverseitige Passkey-Registrierung.

Signal, wenn die Registrierung fehlschlägt

Wenn die Registrierung eines Passkeys fehlschlägt, kann das für den Nutzer verwirrend sein. Wenn im Passkey-Anbieter ein Passkey vorhanden und für den Nutzer verfügbar ist, der zugehörige öffentliche Schlüssel jedoch nicht serverseitig gespeichert ist, schlagen Anmeldeversuche mit dem Passkey immer fehl. Die Fehlerbehebung ist dann schwierig. Informieren Sie den Nutzer in diesem Fall.

Um dies zu verhindern, können Sie dem Passkey-Anbieter mit der Signal API einen unbekannten Passkey melden. Durch Aufrufen von PublicKeyCredential.signalUnknownCredential() mit einer RP-ID und einer Anmeldedaten-ID kann der RP den Passkey-Anbieter darüber informieren, dass die angegebenen Anmeldedaten entfernt wurden oder nicht vorhanden sind. Es liegt im Ermessen des Passkey-Anbieters, wie er mit diesem Signal umgeht. Wenn es unterstützt wird, wird der zugehörige Passkey jedoch voraussichtlich entfernt.

// Detect authentication failure due to lack of the credential
if (response.status === 404) {
  // Feature detection
  if (PublicKeyCredential.signalUnknownCredential) {
    await PublicKeyCredential.signalUnknownCredential({
      rpId: "example.com",
      credentialId: "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA" // base64url encoded credential ID
    });
  } else {
    // Encourage the user to delete the passkey from the password manager nevertheless.
    ...
  }
}

Weitere Informationen zur Signal API finden Sie unter Passkeys mit der Signal API mit Anmeldedaten auf Ihrem Server synchronisieren.

Benachrichtigung an den Nutzer senden

Wenn Nutzer benachrichtigt werden, z. B. per E‑Mail, wenn ein Passkey registriert wird, können sie unbefugte Kontoaufrufe erkennen. Wenn ein Angreifer einen Passkey ohne Wissen des Nutzers erstellt, kann er ihn auch nach einer Passwortänderung weiterhin missbrauchen. Die Benachrichtigung warnt den Nutzer und hilft, dies zu verhindern.

Checkliste

• Bestätigen Sie den Nutzer (vorzugsweise per E-Mail oder über eine sichere Methode), bevor Sie ihm erlauben, einen Passkey zu erstellen.
• Verhindern Sie, dass mit excludeCredentials doppelte Passkeys für denselben Passkey-Anbieter erstellt werden.
• Speichern Sie die AAGUID, um den Passkey-Anbieter zu identifizieren und die Anmeldedaten für den Nutzer zu benennen.
• Weise darauf hin, wenn ein Versuch, einen Passkey zu registrieren, mit PublicKeyCredential.signalUnknownCredential() fehlschlägt.
• Senden Sie dem Nutzer eine Benachrichtigung, nachdem Sie einen Passkey für sein Konto erstellt und registriert haben.

Ressourcen

• Serverseitige Passkey-Registrierung
• Apple-Dokument: Authenticating a User Through a Web Service
• Google-Dokument: Anmeldung ohne Passwort mit Passkeys

Nächster Schritt: Mit einem Passkey über das automatische Ausfüllen von Formularen anmelden.