WebAuthn Signal API: Passkeys clientseitig aktualisieren & löschen

Das Passkey-Ökosystem entwickelt sich ständig weiter. Um diesen Wandel zu ermöglichen, entwickelt sich auch der zugrunde liegende WebAuthn-Standard schnell. Neue Funktionen beginnen oft mit einem technischen 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 Standardentwurf 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 funktioniert die WebAuthn Signal API? Was sind die Empfehlungen für Relying Parties?

Zum Zeitpunkt der Aktualisierung dieses Blogbeitrags im Januar 2025 ist die WebAuthn Signal API seit Chrome 132 standardmäßig aktiviert. Sie war früher als Reporting API bekannt, bevor sie umbenannt wurde, um Konflikte mit einer anderen API gleichen Namens zu vermeiden.

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

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Wenn ein Passkey erstellt wird, enthält er mehrere 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 die tatsächliche Zuordnung des Passkeys zum Konto des Nutzers verwendet wird.
• user.name und user.displayName: dabei handelt es sich um Metadaten, die ausschließlich zu Anzeigezwecken in der Benutzeroberfläche verwendet werden.

Die folgende Abbildung zeigt eine typische, einfache Datenbankstruktur, die erklärt, welche Informationen üblicherweise 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 Nutzer helfen, sein Konto in der Auswahl-Benutzeroberfläche zu identifizieren. Die eigentliche Verknüpfung zwischen einem Passkey und einem Konto wird jedoch über die user.id und die Credential ID aufrechterhalten:

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

Ein Problem entsteht, wenn sich der user.name, der 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, beispielsweise wenn ein Nutzer seine E-Mail-Adresse aktualisiert. Trotz dieser Änderung der Konto-Metadaten auf der Serverseite wird der alte user.name weiterhin in der Anmeldedaten-Auswahl-UI angezeigt, was bei Nutzern zu Verwirrung führen kann.

Die Umgehungslösung für dieses Problem besteht darin, einen neuen Passkey mit dem aktualisierten user.name und der gleichen user.id zu erstellen und dann den vorhandenen Passkey zu überschreiben. Dieser Ansatz ist jedoch aus mehreren Gründen unpraktisch:

1. Redundanz: Jede user.id kann nur einen Passkey pro Relying Party ID haben, was bedeutet, dass der alte Passkey durch einen neuen ersetzt werden muss, was ein zusätzlicher Schritt ist.
2. User Experience: Nutzer werden nicht verstehen, warum sie einen neuen Passkey erstellen müssen. Das ist der Grund, warum diese Umgehungslösung nicht weit verbreitet ist.
3. Komplexität: Die Verwaltung der Passkey-Erstellung und des Austauschs nur zur Aktualisierung von Metadaten ist eine unnötige Komplexität.

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

Become part of our Passkeys Community for updates & support.

Join

Ein weiterer wichtiger Anwendungsfall ist das Löschen von Passkeys auf dem clientseitigen Authenticator. Im Laufe der Zeit können Nutzer Anmeldedaten über die Passkey-Verwaltungsliste widerrufen oder ihre Konten löschen. Dann muss sichergestellt werden, dass diese Anmeldedaten vom clientseitigen Authenticator entfernt werden, um zu verhindern, dass sie in zukünftigen Auswahl-UIs für Anmeldedaten (Conditional UI / Passkey Autofill) erscheinen.

Die Notwendigkeit dieser Funktionalität ergibt sich in mehreren Szenarien:

1. Passkey über Kontoeinstellungen gelöscht: Wenn eine Anmeldeinformation nicht mehr gültig ist, z. B. nachdem ein Nutzer sie explizit über die Kontoeinstellungen gelöscht hat:

Aus Nutzersicht ist es schwer verständlich, dass eine Löschung in den Kontoeinstellungen, in einem Dialog wie dem obigen, nicht dazu führt, dass der Passkey auch auf diesem Client entfernt wird.

2. Kontolöschung: Wenn ein Nutzer sein Konto löscht, sollten auch alle zugehörigen Passkeys entfernt werden.
3. Sicherheitsrichtlinien: Relying Parties können Sicherheitsrichtlinien haben, die den Widerruf von Anmeldedaten nach Phasen der Inaktivität oder aufgrund festgestellter Sicherheitsprobleme erfordern.

Ohne eine direkte Methode zum Löschen von Passkeys auf der Client-Seite überladen diese veralteten oder ungültigen Anmeldedaten weiterhin die Auswahl-UI, was zu Verwirrung führt. Nutzer könnten Passkeys sehen und versuchen zu verwenden, die nicht mehr gültig sind, was zu fehlgeschlagenen Authentifizierungsversuchen und einer schlechten User Experience führt.

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-Anmeldedaten auf dem clientseitigen Authenticator zu aktualisieren oder zu löschen. Dieser Abschnitt beschreibt die wichtigsten Überlegungen und Schritte für die Implementierung.

Bei der Implementierung der WebAuthn Signal API ist es entscheidend, die folgenden Überlegungen zu berücksichtigen:

• Schutz der Privatsphäre: Die WebAuthn Signal API ist darauf ausgelegt, die Privatsphäre der Nutzer zu wahren, da dies eine der Grundlagen von WebAuthn ist. Das bedeutet, dass die RP kein Feedback darüber erhält, ob die angeforderte Änderung verarbeitet wurde. Die API arbeitet im Hintergrund, um jegliches potenzielle Durchsickern von Informationen über den Zustand der Anmeldedaten 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 (z. B. das Vorhandensein eines Security Keys) als auch die Softwareunterstützung (z. B. Browser- und Betriebssystemkompatibilität). Der Browser kann Aktionen nur ausführen, wenn der Authenticator zugänglich ist und die erforderlichen Operationen ohne biometrische Authentifizierung unterstützt.

• Domain-Einschränkungen: Die API stellt sicher, dass nur die Relying Party, die mit einer bestimmten Domain verknüpft ist, Änderungen an Anmeldedaten im Zusammenhang mit dieser Domain anfordern kann. Dies ist eine Sicherheitsmaßnahme, um unbefugte Änderungen durch Dritte zu verhindern.

• Credential ID als Schlüssel: Bei der Referenzierung von Passkeys ist die Credential ID der primäre Schlüssel, der von der WebAuthn Signal API verwendet wird. Diese ID identifiziert den Passkey eindeutig auf dem clientseitigen Authenticator. Die API ermöglicht es RPs, mit Passkeys verknüpfte Metadaten zu ändern oder zu signalisieren, dass auf bestimmte Passkeys nicht mehr zugegriffen werden soll, aber nur über die Credential ID. Falls ein Authenticator eine bestimmte Credential ID nicht kennt, wird er sie stillschweigend ignorieren.

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

Die WebAuthn Signal API bietet einen optimierten Mechanismus für Relying Parties (RPs), um die mit Passkeys verbundenen Metadaten auf clientseitigen Authenticatoren zu aktualisieren. Dies ist besonders wichtig, um sicherzustellen, dass Nutzer genaue und aktuelle Informationen in der Auswahl-UI für Anmeldedaten 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) in der Signal API ist speziell für die Aktualisierung von Passkey-Metadaten konzipiert. Diese Methode ermöglicht es RPs, die aktuellen Werte für user.name und user.displayName bereitzustellen.

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

1. Methodenstruktur: 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: Suchen Sie nach lokal (auf dem Authenticator) verfügbaren Anmeldedaten, die mit der rpId und userId übereinstimmen. Für alle übereinstimmenden Anmeldedaten aktualisiert der Authenticator den name und displayName der Anmeldeinformation.

3. Schutz der Privatsphäre: Der Prozess ist so konzipiert, dass die Privatsphäre gewahrt bleibt. Die Signal API gibt der RP kein Feedback darüber, ob die Aktualisierungen erfolgreich verarbeitet wurden, um ein Durchsickern von Informationen über den Zustand der Anmeldedaten zu verhindern.

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

Im obigen Screenshot sehen Sie, wie Google Chrome dem Nutzer eine solche Aktualisierung signalisiert. Die WebAuthn Signal API ist Teil von Chrome 130 und kann mit dem Google Password Manager auf dem Desktop getestet werden, wenn das Flag für experimentelle Webfunktionen aktiviert ist.

Die WebAuthn Signal API bietet Mechanismen für Relying Parties (RPs), um das Löschen von Passkeys von clientseitigen Authenticatoren zu signalisieren. Dies ist unerlässlich, um sicherzustellen, dass veraltete oder ungültige Anmeldedaten nicht in der Auswahl-UI für Anmeldedaten erscheinen und so eine optimierte und sichere User Experience gewährleistet wird. Es gibt zwei Methoden, um die Passkeys lokal zu löschen: signalUnknownCredential(options) und signalAllAcceptedCredentials(options). Erstere kann in Situationen verwendet werden, in denen der Nutzer nicht authentifiziert ist, während letztere verwendet werden kann, wenn der Nutzer authentifiziert ist. Daher sollte letztere aus Datenschutzgründen bevorzugt werden.

So funktionieren die beiden Methoden:

1. Methodenstruktur: Die Methode signalUnknownCredential(options) enthält die rpId (Relying Party ID) und die credentialId (die eindeutige Kennung der zu löschenden Anmeldeinformation).

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // credential id the user just tried, base64url
});

2. Aufrufen der Methode: RPs rufen diese Methode auf, wann immer sie feststellen, dass eine Anmeldeinformation gelöscht werden sollte. Dies kann unmittelbar nach einem Authentifizierungsversuch mit einer ungültigen Anmeldeinformation, während der Kontolöschung oder wenn ein Nutzer eine Anmeldeinformation über die Kontoeinstellungen widerruft, geschehen.

3. Verarbeiten der Methode: Wenn die Methode signalUnknownCredential(options) aufgerufen wird, versucht der clientseitige Authenticator, Anmeldedaten zu finden, die mit der angegebenen rpId und credentialID übereinstimmen, um sie auszulassen. Abhängig von den Fähigkeiten des Authenticators wird die Anmeldeinformation entfernt oder ein authenticator-spezifisches Verfahren angewendet, um die Anmeldeinformation in zukünftigen Authentifizierungszeremonien auszublenden.

1. Methodenstruktur: Die Methode signalAllAcceptedCredentials(options) enthält die rpId (Relying Party ID), die userId und eine Liste gültiger Credential IDs allAcceptedCredentialIds (Liste eindeutiger Kennungen von Anmeldedaten, die beibehalten werden sollen).

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

2. Aufrufen der Methode: RPs rufen diese Methode auf, wann immer sie feststellen, dass eine Anmeldeinformation gelöscht werden sollte, und signalisieren eine Liste gültiger Anmeldedaten. Diese Methode sollte gegenüber signalUnknownCredential(options) zum Löschen von Anmeldedaten bevorzugt werden.

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

4. Anmeldedaten wieder einblenden: Wenn Anmeldedaten nur ausgeblendet wurden (abhängig vom Authenticator) und nun Teil von allAcceptedCredentialIds sind, werden diese Anmeldedaten in zukünftigen Authentifizierungszeremonien wieder vorhanden sein.

5. Nützliche Tipps:

   • Bei der Verwendung von signalAllAcceptedCredentials(options) ist es wichtig zu beachten, dass Authenticatoren möglicherweise nicht immer verbunden sind, wenn diese Methode ausgeführt wird. Daher könnten Relying Parties in Erwägung ziehen, signalAllAcceptedCredentials(options) regelmäßig auszuführen, z. B. bei jeder Anmeldung, um sicherzustellen, dass alle Anmeldedaten auf dem neuesten Stand sind.
   • Relying Parties müssen vorsichtig sein, wenn sie die Liste der Credential IDs (allAcceptedCredentialIds) angeben. Anmeldedaten, die nicht in dieser Liste enthalten sind, können vom Authenticator ausgeblendet oder entfernt werden, möglicherweise unwiderruflich. Um zu verhindern, dass gültige Anmeldedaten versehentlich ausgelassen werden, ist es entscheidend sicherzustellen, dass die Liste vollständig ist. Wenn eine gültige Credential ID versehentlich ausgelassen wird, 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 Authenticatoren das vorübergehende Ausblenden von Anmeldedaten dem dauerhaften Entfernen vorziehen. Dieser Ansatz kann die Wiederherstellung erleichtern, falls eine gültige Credential ID versehentlich von der Relying Party ausgelassen wurde, und ermöglicht es, sie ohne dauerhaften Verlust wiederherzustellen.

Im obigen Screenshot sehen Sie, wie Google Chrome Löschungen signalisiert. Die WebAuthn Signal API ist Teil von Chrome 132 und 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 Authenticatoren hinweg zu gewährleisten, sollten Sie die folgenden Empfehlungen berücksichtigen:

• Achten Sie auf Updates zur WebAuthn Signal API und die tatsächliche Implementierung: Bleiben Sie über die neuesten Entwicklungen und Updates im Zusammenhang mit der Signal API informiert. Die WebAuthn Signal API ist mit Google Chrome 132 aktiviert, gefolgt von anderen Browsern (z. B. hat Safari ebenfalls Unterstützung angekündigt). Überprüfen Sie regelmäßig den Fortschritt und die Updates zur WebAuthn Signal API, um sicherzustellen, dass Ihre Implementierung den neuesten Standards und Praktiken entspricht. Wir werden diesen Blogbeitrag in Zukunft aktualisieren; er basiert derzeit auf den Informationen, die am 14. Januar 2025 verfügbar waren.
• Beginnen Sie mit dem signalAllAcceptedCredentials(options)-Ansatz nach jeder erfolgreichen Anmeldung: Dieser Ansatz stellt sicher, dass alle Metadaten und Credential IDs in einer einzigen Methode aktualisiert werden, was den Prozess vereinfacht und die Konsistenz über Geräte und Plattformen hinweg aufrechterhält und gleichzeitig gelöschte oder veraltete Anmeldedaten deaktiviert.
• Echtzeit-Benachrichtigungen mit signalUnknownCredential(options) für groß angelegte Implementierungen: Erwägen Sie die Verwendung von Echtzeit-Benachrichtigungen mit der Methode signalUnknownCredential(options) in groß angelegten Implementierungen oder wenn sofortige Aktualisierungen erforderlich sind. Diese Methode kann die Effizienz und Genauigkeit der Anmeldedatenverwaltung verbessern und sicherstellen, dass ungültige oder veraltete Anmeldedaten umgehend aus der Auswahl-UI entfernt werden.

Indem Sie diese Empfehlungen befolgen, können Sie die WebAuthn Signal API effektiv implementieren, sobald sie unterstützt wird, und sicherstellen, dass die Passkey-Metadaten auf allen clientseitigen Authenticatoren aktuell und konsistent bleiben, was eine reibungslose und sichere User Experience für Passkeys bietet.

Der WebAuthn-Standard entwickelt sich kontinuierlich weiter und wird von Monat zu Monat funktionsreicher. Die Einführung der WebAuthn Signal API ist ein bedeutender Schritt vorwärts bei der Verwaltung von Passkey-Metadaten und Löschungen auf clientseitigen Authenticatoren. Diese API deckt die entscheidenden Anwendungsfälle ab, Informationen zwischen Relying Parties (RPs) und Authenticatoren synchron zu halten und sicherzustellen, dass ungültige oder veraltete Passkeys entfernt werden, wodurch die User Experience verbessert wird.

• Warum wird die Signal API benötigt? Die Signal API ist unerlässlich für die Aktualisierung von Passkey-Metadaten und das Löschen von Passkeys auf clientseitigen Authenticatoren. Sie löst Probleme im Zusammenhang mit veralteten user.name- und user.displayName-Informationen, die zu Verwirrung führen können, wenn Anmeldedaten in der Auswahl-UI angezeigt werden. Zusätzlich hilft sie dabei, eine saubere und sichere Benutzeroberfläche für die Anmeldedatenauswahl aufrechtzuerhalten, indem sie widerrufene oder gelöschte Passkeys entfernt.
• Wie funktioniert die Signal API? Die Signal API funktioniert, indem sie es RPs ermöglicht, Methoden über den aktuellen Zustand von Anmeldedaten aufzurufen, einschließlich Aktualisierungen von Metadaten und dem Signalisieren der Löschung von Passkeys. Diese Meldungen werden vom clientseitigen Authenticator verarbeitet, um sicherzustellen, dass die den Nutzern präsentierten Informationen korrekt und aktuell sind. Die API ist so konzipiert, dass sie die Privatsphäre wahrt und ohne Feedback an die RP über den Erfolg der Aktualisierungen arbeitet.

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