WebAuthn Signal API: Passkeys clientseitig aktualisieren & löschen

Looking for a dev-focused passkey reference? Download our Passkeys Cheat Sheet. Trusted by dev teams at Ally, Stanford CS & more.

Get Cheat Sheet

Zuletzt aktualisiert: 4. November 2025

Hier ein kurzer Überblick über die Unterstützung der WebAuthn Signal API auf verschiedenen Plattformen:

⚠️ Bekanntes Problem: Safari 26+ hat einen Bug, bei dem das Promise nicht korrekt aufgelöst wird (WebKit Bug #298951). Ein Fix steht noch aus.

Das Passkey-Ökosystem entwickelt sich rasant weiter. Um diesen Wandel zu ermöglichen, wird auch der zugrunde liegende WebAuthn-Standard ständig angepasst. Neue Funktionen beginnen oft als technischer "Explainer" auf GitHub und werden dann zu einem Pull Request für den Standard, sobald sie ausreichend diskutiert wurden. Kürzlich wurde dieser Pull Request als WebAuthn Signal API in den Standard-Entwurf aufgenommen.

In diesem Artikel behandeln wir:

• Warum wird die WebAuthn Signal API benötigt: Welche Anwendungsfälle unterstützt die WebAuthn Signal API?
• Wie funktioniert die WebAuthn Signal API: Wie genau arbeitet die API? Was sind die Empfehlungen für Relying Parties?

Zum Zeitpunkt dieses Artikels ist die WebAuthn Signal API standardmäßig ab Chrome 132 aktiviert. Früher war sie als "Reporting API" bekannt, wurde aber umbenannt, um Konflikte mit einer anderen API gleichen Namens zu vermeiden.

Die WebAuthn Signal API adressiert spezifische Anwendungsfälle im Zusammenhang mit der Verwaltung von Passkeys auf der Client-Seite. Konkret hilft sie dabei, Informationen zwischen der Relying Party (RP) und den Authenticators, die Teil der clientseitigen Betriebssysteme sind, synchron zu halten. Es gibt folgende wichtige Anwendungsfälle:

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Wenn ein Passkey erstellt wird, enthält er verschiedene Informationen: user.id, user.name und user.displayName. Der Passkey selbst wird über die eindeutige Credential ID identifiziert.

• user.id: ist eine eindeutige Kennung, die das Konto repräsentiert, mit dem der Passkey verknüpft ist. Diese user.id ist entscheidend, da sie für den eigentlichen Abgleich des Passkeys mit dem Benutzerkonto verwendet wird.
• user.name und user.displayName: Dies sind Metadaten, die ausschließlich zu Anzeigezwecken in der Benutzeroberfläche verwendet werden.

Die folgende Grafik zeigt eine typische, einfache Datenbankstruktur und erklärt, welche Informationen normalerweise in welchem Feld gespeichert werden:

Es ist wichtig zu verstehen, dass user.name (oft eine E-Mail-Adresse) und user.displayName (ein freundlicherer, lesbarer Name) dem Benutzer zwar helfen, sein Konto in der Auswahl-UI zu identifizieren, die eigentliche Verknüpfung zwischen einem Passkey und einem Konto jedoch über die user.id und die Credential ID erfolgt:

• Ein Konto kann mehrere Passkeys haben, aber jeder Passkey wird über die user.id eindeutig identifiziert und dem Konto zugeordnet.
• Jeder Passkey selbst hat eine einzigartige Credential ID, die vom Authenticator generiert wird.

Ein Problem entsteht, wenn sich der user.name, der beispielsweise eine E-Mail-Adresse sein kann, ändert. Derzeit gibt es keinen Mechanismus, um diese Änderung direkt auf dem clientseitigen Authenticator zu aktualisieren. Der user.name kann sich aus verschiedenen Gründen ändern, etwa wenn ein Benutzer seine E-Mail-Adresse aktualisiert. Trotz dieser Änderung der Konto-Metadaten auf der Server-Seite wird der alte user.name weiterhin in der Credential-Auswahl-UI angezeigt, was bei Benutzern zu Verwirrung führen kann.

Der Workaround für dieses Problem besteht darin, einen neuen Passkey mit dem aktualisierten user.name und derselben user.id zu erstellen und den bestehenden Passkey zu überschreiben. Dieser Ansatz ist jedoch aus mehreren Gründen unpraktisch:

1. Redundanz: Ein Authenticator kann nur einen Passkey pro user.id für eine spezifische Relying Party ID speichern. Das bedeutet, der alte Passkey muss durch einen neuen ersetzt werden, um Metadaten zu aktualisieren – ein zusätzlicher Schritt.
2. User Experience (UX): Benutzer verstehen oft nicht, warum sie einen neuen Passkey erstellen müssen. Deshalb ist dieser Workaround nicht weit verbreitet.
3. Komplexität: Die Verwaltung von Passkey-Erstellung und -Austausch nur zur Aktualisierung von Metadaten ist unnötig komplex.

E-Mail-Adressen, Telefonnummern und andere Identifikatoren können sich regelmäßig ändern. Ohne eine einfache Methode, user.name und user.displayName direkt auf dem Authenticator zu aktualisieren, stoßen Benutzer auf das dauerhafte Problem, dass sie einen Passkey sehen und auswählen müssen, der mit ihrer alten E-Mail-Adresse verknüpft ist. Diese Situation untergräbt die nahtlose Erfahrung, die Passkeys eigentlich bieten sollen. Die WebAuthn Signal API zielt darauf ab, dieses Problem zu lösen, indem sie Relying Parties ermöglicht, Updates an den Metadaten von Passkeys zu melden, ohne dass neue erstellt werden müssen. Bevor wir die Implementierung der Signal API erklären, schauen wir uns den zweiten wichtigen Anwendungsfall an.

Become part of our Passkeys Community for updates & support.

Join

Ein weiterer entscheidender Anwendungsfall ist das Löschen von Passkeys auf dem clientseitigen Authenticator. Im Laufe der Zeit können Benutzer Anmeldeinformationen über ihre Passkey-Verwaltungsliste widerrufen oder ihre Konten löschen. Es muss sichergestellt werden, dass diese Anmeldeinformationen auch vom clientseitigen Authenticator entfernt werden, damit sie nicht in zukünftigen Auswahl-UIs (Conditional UI / Passkey Autofill) erscheinen.

Die Notwendigkeit für diese Funktion ergibt sich in mehreren Szenarien:

1. Passkey über Kontoeinstellungen gelöscht: Wenn ein Credential nicht mehr gültig ist, z. B. nachdem ein Benutzer es explizit über die Kontoeinstellungen gelöscht hat:

Aus Benutzersicht ist schwer verständlich, warum eine Löschung in den Kontoeinstellungen (wie im obigen Dialog) nicht dazu führt, dass der Passkey auch auf diesem Gerät entfernt wird.

2. Kontolöschung: Wenn ein Benutzer sein Konto löscht, sollten auch alle zugehörigen Passkeys entfernt werden.

3. Sicherheitsrichtlinien: Relying Parties haben möglicherweise Sicherheitsrichtlinien, die den Widerruf von Credentials nach Inaktivitätsphasen oder aufgrund erkannter Sicherheitsprobleme erfordern.

Ohne eine direkte Methode zum Löschen von Passkeys auf der Client-Seite überfluten diese veralteten oder ungültigen Credentials weiterhin die Auswahl-UI, was zu Verwirrung führt. Benutzer sehen möglicherweise Passkeys, die nicht mehr gültig sind, und versuchen, diese zu verwenden, was zu fehlgeschlagenen Authentifizierungsversuchen und einer schlechten UX führt.

Seht euch dieses Video an, um zu erfahren, wie man serverseitige Passkeys in der Corbado Connect Management Console löscht:

Die Implementierung der WebAuthn Signal API umfasst mehrere Schritte und Überlegungen, um sicherzustellen, dass die Funktionalität korrekt und sicher integriert wird. Die Signal API ermöglicht es Relying Parties (RPs), Passkey-Credentials auf dem clientseitigen Authenticator zu aktualisieren oder zu löschen. Dieser Abschnitt beschreibt die wichtigsten Überlegungen und Schritte zur Implementierung.

Bei der Implementierung der WebAuthn Signal API solltet ihr folgende Punkte beachten:

• Datenschutzfreundlich (Privacy Preserving): Die WebAuthn Signal API ist darauf ausgelegt, die Privatsphäre der Nutzer zu wahren, da dies eines der Fundamente von WebAuthn ist. Das bedeutet, dass die RP kein Feedback darüber erhält, ob die angeforderte Änderung verarbeitet wurde. Die API arbeitet still im Hintergrund, um potenzielle Informationslecks über den Status von Credentials zu verhindern.

• Verfügbarkeit des Authenticators: Die Wirksamkeit der WebAuthn Signal API hängt von der Verfügbarkeit des Authenticators ab. Dies umfasst sowohl die physische Verfügbarkeit als auch die Softwareunterstützung (z. B. Browser- und Betriebssystemkompatibilität). Der Browser kann Aktionen nur durchführen, wenn der Authenticator zugänglich ist und die erforderlichen Operationen ohne Notwendigkeit einer biometrischen Authentifizierung unterstützt.

• Domain-Beschränkungen: Die API stellt sicher, dass nur die Relying Party, die mit einer bestimmten Domain verbunden ist, Änderungen an Credentials für diese Domain anfordern kann. Dies ist eine Sicherheitsmaßnahme, um unbefugte Änderungen durch Dritte zu verhindern.

• Credential ID als Schlüssel: Wenn auf Passkeys Bezug genommen wird, ist die Credential ID der Primärschlüssel, den die WebAuthn Signal API verwendet. Diese ID identifiziert den Passkey auf dem clientseitigen Authenticator eindeutig. Die API erlaubt RPs, Metadaten von Passkeys zu ändern oder zu signalisieren, dass bestimmte Passkeys nicht mehr verwendet werden sollen, jedoch nur über die Credential ID. Falls ein Authenticator eine spezifische Credential ID nicht kennt, wird er die Anfrage stillschweigend ignorieren.

Diese Überlegungen sind essenziell, um die wichtigsten Aspekte der Funktionsweise der WebAuthn Signal API zu verstehen.

Die WebAuthn Signal API bietet einen optimierten Mechanismus für Relying Parties (RPs), um die mit Passkeys verknüpften Metadaten auf clientseitigen Authenticators zu aktualisieren. Dies ist besonders wichtig, um sicherzustellen, dass Benutzer genaue und aktuelle Informationen in der Credential-Auswahl-UI sehen, ohne unnötig neue Passkeys erstellen zu müssen. So ermöglicht die API dies:

Metadaten aktualisieren mit signalCurrentUserDetails(options)

Die Methode signalCurrentUserDetails(options) der Signal API ist speziell für die Aktualisierung von Passkey-Metadaten konzipiert. Diese Methode erlaubt RPs, die aktuellen Werte für user.name und user.displayName bereitzustellen.

So funktioniert der Prozess (siehe auch den WebAuthn Level 3 Standard):

1. Struktur der Methode: Die Methode signalCurrentUserDetails(options) enthält die rp.id, user.id und die aktualisierten Werte für user.name und user.displayName.

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "aabbcc", // User-Handle, base64url.
    name: "New user name",
    displayName: "New display name",
});

2. Aktualisierung der lokalen Metadaten: Es wird nach lokal (auf dem Authenticator) verfügbaren Credentials gesucht, die zur rpId und userId passen. Für alle übereinstimmenden Credentials aktualisiert der Authenticator name und displayName.

3. Datenschutz: Der Prozess ist datenschutzfreundlich gestaltet. Die Signal API gibt der RP keine Rückmeldung darüber, ob die Updates erfolgreich verarbeitet wurden, um Informationslecks über den Status der Credentials zu vermeiden.

4. Konsistenz über Geräte hinweg: Durch regelmäßiges Ausführen der Methode signalCurrentUserDetails(options) können RPs sicherstellen, dass die Metadaten für Passkeys auf verschiedenen Geräten und Plattformen, auf denen sich der Benutzer authentifiziert, konsistent bleiben. Dieser Ansatz reduziert die Wahrscheinlichkeit, dass veraltete oder falsche Informationen in der Credential-Auswahl-UI angezeigt werden.

Im obigen Screenshot seht ihr, wie Google Chrome ein solches Update dem Benutzer signalisiert. Die WebAuthn Signal API ist Teil von Chrome und kann mit dem Google Password Manager auf dem Desktop getestet werden.

Die WebAuthn Signal API bietet Mechanismen für Relying Parties (RPs), um das Löschen von Passkeys auf clientseitigen Authenticators zu signalisieren. Dies ist essenziell, um sicherzustellen, dass veraltete oder ungültige Credentials nicht in der Auswahl-UI erscheinen und so eine schlanke und sichere Benutzererfahrung gewahrt bleibt. Es gibt zwei Methoden, um Passkeys lokal zu löschen: signalUnknownCredential(options) und signalAllAcceptedCredentials(options). Erstere kann in Situationen verwendet werden, in denen der Benutzer nicht authentifiziert ist, während letztere verwendet werden kann, wenn der Benutzer authentifiziert ist. Daher sollte die zweite Methode aus Datenschutzgründen bevorzugt werden.

So funktionieren die beiden Methoden:

1. Struktur der Methode: Die Methode signalUnknownCredential(options) beinhaltet die rpId (Relying Party ID) und die credentialId (die eindeutige Kennung des zu löschenden Credentials).

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // Credential ID, die der User gerade versucht hat, base64url
});

2. Aufruf der Methode: RPs rufen diese Methode auf, wann immer sie feststellen, dass ein Credential gelöscht werden sollte. Dies könnte unmittelbar nach einem Authentifizierungsversuch mit einem ungültigen Credential sein, während einer Kontolöschung oder wenn ein Benutzer ein Credential über die Kontoeinstellungen widerruft.

3. Verarbeitung der Methode: Wenn die Methode signalUnknownCredential(options) aufgerufen wird, versucht der clientseitige Authenticator, Credentials zu finden, die mit rpId und credentialId übereinstimmen. Abhängig von den Fähigkeiten des Authenticators wird das Credential entfernt oder ein authenticator-spezifisches Verfahren angewendet, um das Credential in zukünftigen Authentifizierungs-Abläufen zu verbergen.

1. Struktur der Methode: Die Methode signalAllAcceptedCredentials(options) enthält die rpId (Relying Party ID), userId und eine Liste gültiger Credential IDs in allAcceptedCredentialIds (Liste der eindeutigen Kennungen von Credentials, die behalten werden sollen).

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "aabbcc", // User-Handle, base64url.
    allAcceptedCredentialIds: ["bb"],
});

2. Aufruf der Methode: RPs rufen diese Methode auf, wann immer sie feststellen, dass ein Credential gelöscht werden sollte, und signalisieren eine Liste der gültigen Credentials. Diese Methode sollte gegenüber signalUnknownCredential(options) bevorzugt werden, um Credentials zu löschen.

3. Verarbeitung der Methode: Wenn die Methode signalAllAcceptedCredentials(options) aufgerufen wird, gleicht der clientseitige Authenticator die rpId und userId ab. Der Authenticator sucht alle lokalen Credentials, die zu rpId und userId passen. Das Ergebnis wird mit allAcceptedCredentialIds verglichen. Wenn es lokale Credentials gibt, die nicht in allAcceptedCredentialIds enthalten sind, werden diese Credentials lokal entfernt (oder je nach Authenticator verborgen).

4. Credentials wieder sichtbar machen: Wenn Credentials lediglich verborgen wurden (abhängig vom Authenticator) und nun wieder Teil von allAcceptedCredentialIds sind, werden diese Credentials in zukünftigen Authentifizierungs-Abläufen wieder präsent sein.

5. Nützliche Tipps:

   • Bei der Verwendung von signalAllAcceptedCredentials(options) ist zu beachten, dass Authenticators zum Zeitpunkt der Ausführung dieser Methode möglicherweise nicht immer verbunden sind. Daher sollten Relying Parties erwägen, signalAllAcceptedCredentials(options) periodisch auszuführen, z. B. bei jedem Login, um sicherzustellen, dass alle Credentials aktuell sind.
   • Relying Parties müssen vorsichtig sein, wenn sie die Liste der Credential IDs (allAcceptedCredentialIds) spezifizieren. Credentials, die nicht in dieser Liste enthalten sind, können vom Authenticator verborgen oder entfernt werden, möglicherweise irreversibel. Um zu verhindern, dass gültige Credentials versehentlich weggelassen werden, muss sichergestellt werden, dass die Liste vollständig ist. Falls eine gültige Credential ID versehentlich ausgelassen wurde, sollte sie so schnell wie möglich wieder zu signalAllAcceptedCredentials(options) hinzugefügt werden, um sie wieder sichtbar zu machen, vorausgesetzt, der Authenticator unterstützt dies.
   • Wann immer möglich, sollten Authenticators das vorübergehende Verbergen von Credentials dem permanenten Entfernen vorziehen. Dieser Ansatz erleichtert die Wiederherstellung, falls eine gültige Credential ID versehentlich von der Relying Party ausgelassen wurde, und ermöglicht die Wiederherstellung ohne dauerhaften Verlust.

Im obigen Screenshot seht ihr, wie Google Chrome Löschvorgänge signalisiert. Die WebAuthn Signal API kann mit dem Google Password Manager auf dem Desktop getestet werden.

Um die WebAuthn Signal API effektiv zu implementieren und eine nahtlose Synchronisierung von Passkey-Metadaten über clientseitige Authenticators hinweg sicherzustellen, solltet ihr folgende Empfehlungen beachten:

• Achtet auf Updates der WebAuthn Signal API und die tatsächliche Implementierung: Bleibt über die neuesten Entwicklungen und Updates zur Signal API informiert. Die WebAuthn Signal API ist ab Google Chrome 132 aktiviert, gefolgt von anderen Browsern (z. B. hat Safari ebenfalls Unterstützung angekündigt). Prüft regelmäßig den Fortschritt und Updates der WebAuthn Signal API, um sicherzustellen, dass eure Implementierung den neuesten Standards und Praktiken entspricht. Wir werden diesen Blogpost aktualisieren, sobald sich die Landschaft weiterentwickelt.
• Startet mit dem signalAllAcceptedCredentials(options)-Ansatz nach jedem erfolgreichen Login: Dieser Ansatz stellt sicher, dass alle Metadaten und Credential IDs in einem einzigen Methodenaufruf aktualisiert werden, was den Prozess vereinfacht, Konsistenz über Geräte und Plattformen hinweg wahrt und gleichzeitig gelöschte oder veraltete Credentials deaktiviert.
• Echtzeit-Messaging mit signalUnknownCredential(options) für große Deployments: Zieht Echtzeit-Messaging mit der Methode signalUnknownCredential(options) für große Deployments in Betracht oder wenn sofortige Updates erforderlich sind. Diese Methode kann die Effizienz und Genauigkeit des Credential-Managements verbessern und sicherstellen, dass ungültige oder veraltete Credentials umgehend aus der Auswahl-UI entfernt werden.

Indem ihr diesen Empfehlungen folgt, könnt ihr die WebAuthn Signal API effektiv implementieren, sobald sie unterstützt wird. So stellt ihr sicher, dass Passkey-Metadaten aktuell und konsistent über alle clientseitigen Authenticators hinweg bleiben und bietet damit eine reibungslose und sichere Benutzererfahrung für Passkeys.

Der WebAuthn-Standard entwickelt sich ständig weiter und wird monatlich funktionsreicher. Die Einführung der WebAuthn Signal API ist ein bedeutender Schritt vorwärts im Management von Passkey-Metadaten und Löschungen auf clientseitigen Authenticators. Diese API adressiert die entscheidenden Anwendungsfälle der Synchronisierung von Informationen zwischen Relying Parties (RPs) und Authenticators und stellt sicher, dass ungültige oder veraltete Passkeys entfernt werden, was die Benutzererfahrung verbessert.

• Warum wird die Signal API benötigt? Die Signal API ist essenziell für die Aktualisierung von Passkey-Metadaten und das Löschen von Passkeys auf clientseitigen Authenticators. Sie löst Probleme im Zusammenhang mit veralteten user.name- und user.displayName-Informationen, die zu Verwirrung führen können, wenn Credentials in der Auswahl-UI präsentiert werden. Zusätzlich hilft sie dabei, eine saubere und sichere Credential-Auswahl-Schnittstelle zu bewahren, indem widerrufene oder gelöschte Passkeys entfernt werden.
• Wie funktioniert die Signal API? Die Signal API ermöglicht es RPs, Methoden über den aktuellen Status von Credentials aufzurufen, einschließlich Updates von Metadaten und der Signalisierung von Passkey-Löschungen. Diese Berichte werden vom clientseitigen Authenticator verarbeitet und stellen sicher, dass die den Benutzern präsentierten Informationen korrekt und aktuell sind. Die API ist datenschutzfreundlich konzipiert und arbeitet ohne Rückmeldung an die RP über den Erfolg der Updates.

Da sich der WebAuthn-Standard weiterentwickelt, profitiert er von den vielfältigen Interessen seiner Teilnehmer, die verschiedene Teile des Standards vorantreiben. Ein Auge auf diese Entwicklungen zu haben, ist entscheidend, um bei den neuesten Verbesserungen auf dem Laufenden zu bleiben und sicherzustellen, dass Implementierungen mit den neuesten Best Practices und Standards übereinstimmen. Die WebAuthn-Community treibt die Innovation weiter voran und macht die Authentifizierung sicherer und benutzerfreundlicher.