WebAuthn Client-Fähigkeiten

Passkeys Cheat Sheet — dev-focused WebAuthn reference. Trusted by Ally, Stanford CS & more.

Get Cheat Sheet

WebAuthn ist der moderne Standard hinter Passkeys. Anstatt sich auf herkömmliche Passwörter zu verlassen, nutzt er Public-Key-Kryptografie. Das ermöglicht es Nutzern, sich mit Passkeys zu authentifizieren, die auch Biometrie (wie Fingerabdruck oder Gesichtserkennung) oder physische Security Keys umfassen können. Dieser Wechsel erhöht nicht nur die Sicherheit, sondern verbessert auch die User Experience, da das lästige Passwort-Management entfällt.

Der WebAuthn Level 3 Standard führt neue Client-Fähigkeiten (Client Capabilities) ein, die über die Browser-API getClientCapabilities() abgerufen werden können. Diese Neuerungen geben Plattformen und Entwicklerteams mehr Kontrolle und Flexibilität bei der Implementierung von Passkeys. Sie vereinfachen die geräte- und browserübergreifende Passkey-Integration und sorgen für eine reibungslosere und konsistentere User Journey.

In diesem Blogpost beantworten wir folgende Fragen:

1. Was sind WebAuthn Client-Fähigkeiten?
2. Welche WebAuthn Client-Fähigkeiten gibt es?
3. Wie verbessern WebAuthn Client-Fähigkeiten Passkey-Implementierungen?
4. Warum sind diese Fähigkeiten für Entwickler und Produktmanager wichtig?

Am Ende werden Sie verstehen, wie Sie mit diesen Features nahtlose, sichere Authentifizierungsabläufe schaffen können, die den modernen Erwartungen der Nutzer entsprechen.

WebAuthn Client-Fähigkeiten sind eine Reihe von Funktionen, mit denen Browser und Plattformen kommunizieren können, welche WebAuthn-Funktionalitäten sie unterstützen. Einfach gesagt wirken sie wie eine Feature-Checkliste, die Websites mitteilt, welche Authentifizierungsmethoden und Einstellungen auf dem Gerät eines Nutzers verfügbar sind. Dadurch lassen sich Authentifizierungsabläufe optimal auf die Fähigkeiten des Clients zuschneiden – für eine flüssigere und sicherere Benutzererfahrung.

Wenn ein Browser beispielsweise signalisiert, dass er biometrische Authentifizierung (wie Touch ID) unterstützt, können die Login-Flows so gestaltet werden, dass dem Nutzer der Login per Fingerabdruck direkt angeboten wird. Fehlen bestimmte Features hingegen, können nahtlos Fallback-Optionen wie ein Passwort oder ein SMS-OTP bereitgestellt werden. In der Praxis können nicht unterstützte oder abgebrochene Abläufe immer noch als allgemeine Browser-Fehler auftreten. Deshalb ist es sinnvoll, diese Ergebnisse einer expliziten WebAuthn-Fehlerklassifizierung zuzuordnen.

Der WebAuthn Level 3 Standard bringt mehrere neue Client-Fähigkeiten mit sich, die Passkey-Implementierungen vielseitiger und nutzerfreundlicher machen. Die erste Unterstützung für den API-Aufruf getClientCapabilities() wurde mit Safari 17.4 eingeführt.

Um den Support im Browser zu prüfen, ist folgendes Snippet hilfreich:

// Prüfen, ob PublicKeyCredential im aktuellen Browser unterstützt wird
if (typeof PublicKeyCredential === "undefined") {
    console.log("PublicKeyCredential wird in diesem Browser nicht unterstützt.");
}
 
// Prüfen, ob die Methode getClientCapabilities bei PublicKeyCredential existiert
if (typeof PublicKeyCredential.getClientCapabilities === "function") {
    try {
        let capabilities = await PublicKeyCredential.getClientCapabilities();
        console.log(capabilities);
    } catch (error) {
        console.error("Fehler beim Abrufen der Client-Fähigkeiten:", error);
    }
} else {
    console.log("getClientCapabilities wird in diesem Browser nicht unterstützt");
}

Mit getClientCapabilities() können Websites und Apps den Client (z. B. den Browser oder das Gerät) abfragen, um festzustellen, welche WebAuthn-Features unterstützt werden. Wenn wir die Fähigkeiten des Clients kennen, können wir unsere Login-Flows so optimieren, dass verfügbare Features (wie biometrische Authentifizierung) genutzt und bei Bedarf alternative Methoden angeboten werden.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Hier ist ein genauerer Blick auf die WebAuthn Client-Fähigkeiten und wie sie die Passkey-Integration beeinflussen:

conditionalCreate ermöglicht die automatische Passkey-Erstellung basierend auf bestimmten Bedingungen. Eine Anwendung könnte diese Fähigkeit nutzen, um während eines Passwort-Autofills automatisch einen Passkey zu erstellen, sofern der Passwort-Manager dies unterstützt. Dieses Feature hilft enorm dabei, die Passkey-Adoption voranzutreiben, da Nutzer ganz automatisch von Passwörtern zu Passkeys überführt werden.

Ähnlich wie conditionalCreate löst conditionalGet Passkey-Logins automatisch aus. Das ist ideal für Szenarien, in denen die bestmögliche Passkey-UX geboten werden soll: Der Login wird nicht nur passwortlos, sondern auch "usernameless" (Nutzer klicken einfach in einem Modal/Dropdown auf den gewünschten Passkey und sind authentifiziert). Durch diese Funktion stellen wir sicher, dass die Passkey-Authentifizierung nur dann aufgerufen wird, wenn es auch passt, was unnötige Prompts minimiert und die UX verbessert.

hybridTransport stellt sicher, dass Passkeys geräteübergreifend genutzt werden können (via QR-Code und Bluetooth). So könnte sich jemand beispielsweise an einem Desktop-Rechner bei einem Dienst anmelden, indem er einen auf seinem Smartphone gespeicherten Passkey nutzt. Diese Fähigkeit ermöglicht eine sichere Authentifizierung, ohne dass Passkeys übertragen oder auf herkömmliche Login-Methoden für jedes einzelne Gerät zurückgegriffen werden muss.

Plattform-Authenticatoren wie Windows Hello, Face ID oder Touch ID sind direkt in die Geräte integriert. Sie bieten eine schnellere, flüssigere und sicherere Passkey-Erfahrung, da sie die Authentifizierung mit Biometrie oder anderen geräteeigenen Methoden (z. B. PIN oder Wischmuster) ermöglichen.

Become part of our Passkeys Community for updates & support.

Join

userVerifyingPlatformAuthenticator stellt sicher, dass bei der Passkey-Authentifizierung eine Benutzerverifizierung (User Verification) stattfindet – beispielsweise durch einen aktiven Fingerabdruck-Scan oder Gesichtserkennung. Das bietet eine zusätzliche Sicherheitsebene.

Die Fähigkeit relatedOrigins ermöglicht eine nahtlose Authentifizierung über verschiedene Domains hinweg, die derselben Organisation gehören (z. B. amazon.com und amazon.de). Wenn ein Unternehmen mehrere Domains oder Subdomains verwaltet, können sich Nutzer einmal einloggen und auf alle Bereiche zugreifen, ohne sich auf jeder Domain neu authentifizieren zu müssen. Das reduziert Reibungsverluste und ist besonders für Unternehmen im internationalen Umfeld oder mit Multi-Service-Plattformen wertvoll.

Die Methode signalAllAcceptedCredentials(options) stellt die komplette Liste der WebAuthn Credential IDs für einen bestimmten Nutzer bereit. WebAuthn Relying Parties sollten diese Methode gegenüber signalUnknownCredential() bevorzugen, wenn der Nutzer bereits authentifiziert ist, da so kein Risiko für Privacy Leaks besteht. Diese Methode bietet einen umfassenden Überblick über die Public Key Credentials eines Nutzers, einschließlich kürzlich vorgenommener Änderungen, die möglicherweise auf aktuell verbundenen Authenticatoren noch nicht aktualisiert wurden.

Schauen wir uns ein Beispiel an: Ein Nutzer (userId: A) hat 2 Passkeys mit Credential IDs, die als X und Y Base64URL-kodiert sind. Dann löscht der Nutzer Passkey X in den Kontoeinstellungen des Webdienstes (example.com). Der Public Key wird also serverseitig gelöscht. Nun führen wir folgendes Snippet aus:

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "A", // WebAuthn User Handle, Base64URL.
    allAcceptedCredentialIds: ["Y"],
});

Wenn der Authenticator zum Zeitpunkt der Ausführung verfügbar ist, löscht oder verbirgt er Passkey X für zukünftige Authentifizierungen. Da der Authenticator jedoch nicht immer zwingend verbunden ist, sollten Relying Parties diesen Code regelmäßig ausführen, z. B. bei jedem Login.

Passkeys, die nicht in allAcceptedCredentialIds vorhanden sind, werden möglicherweise irreversibel entfernt oder verborgen. Relying Parties müssen also gut aufpassen, dass gültige WebAuthn Credential IDs niemals aus der Liste entfernt werden. Wurde eine gültige Credential ID versehentlich entfernt, sollte die Relying Party sie schnellstmöglich in einen weiteren signalAllAcceptedCredentials(options)-Aufruf aufnehmen, um den Passkey wieder "einzublenden". Wenn der Passkey nicht nur verborgen, sondern gelöscht wurde, lässt sich dies in der Regel nicht mehr rückgängig machen.

Experiment with passkey flows in the Passkeys Debugger.

Try for Free

Die Methode signalCurrentUserDetails(options) signalisiert den aktuellen Namen und den WebAuthn Display Name des Nutzers. Wenn signalCurrentUserDetails(options) aufgerufen wird, führt der Client eine Reihe definierter Schritte aus, um diese Aktion auszuführen.

Auch hier ein Beispiel: Ein Nutzer mit der WebAuthn User ID A ändert seinen Namen in den Kontoeinstellungen einer Website (example.com). Anschließend kann die Relying Party folgenden Code ausführen:

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "A", // User ID, Base64URL.
    name: "Neuer Benutzername",
    displayName: "Neuer Anzeigename",
});

Der Authenticator aktualisiert daraufhin die Metadaten des lokal gespeicherten Passkeys. Der große Vorteil: Bei zukünftigen Conditional UI / Passkey-Autofill-Anfragen zeigt das Auswahlmenü direkt den aktualisierten Namen und WebAuthn Display Name an.

Die Methode signalUnknownCredential(options) signalisiert, dass eine WebAuthn Credential ID von der WebAuthn Relying Party nicht erkannt wird – zum Beispiel, weil der Passkey vom Nutzer gelöscht wurde. Im Gegensatz zu signalAllAcceptedCredentials(options) ist hier nicht die komplette Liste der akzeptierten Credential IDs und das WebAuthn User Handle erforderlich. Das verhindert potenzielle Privacy Leaks bei unauthentifizierten Aufrufern.

Ein Beispiel dazu: Ein Nutzer löscht einen Passkey mit der Credential ID X in den Kontoeinstellungen einer Website (example.com). Der Public Key wird gelöscht, aber der Private Key ist auf dem Gerät des Nutzers noch vorhanden. Bei zukünftigen Conditional UI / Passkey-Autofill-Anfragen (mit einer leeren allowCredentials-Liste) kann der Passkey immer noch ausgewählt werden. Der Login-Versuch wird jedoch fehlschlagen, da der Public Key bereits gelöscht ist. Die Relying Party sollte daher Folgendes ausführen:

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "X", // Credential ID, die der Nutzer gerade versucht hat, Base64URL
});

Der Authenticator löscht oder verbirgt dann den Passkey mit der Credential ID X bei zukünftigen Login-Versuchen.

Da sich der WebAuthn Level 3 Standard noch im Entwurfsstadium befindet, ist die Unterstützung dieser neuen Client-Fähigkeiten noch nicht flächendeckend. Verschiedene Browser implementieren die Features nach und nach. Hier ist ein aktueller Überblick zur Verfügbarkeit in den großen Browsern:

Die Akzeptanz wird voraussichtlich steigen, je weiter Level 3 reift und mehr Browser diese Funktionen ausliefern. Wenn Sie sehen möchten, wie viele Nutzer getClientCapabilities() aktuell schon nutzen können, werfen Sie einen Blick auf die Echtdaten bei State of Passkeys. Behalten Sie Browser-Release-Notes im Auge, um für eine breitere Kompatibilität zu planen.

See how many people actually use passkeys.

View Adoption Data

Vielleicht fragen Sie sich, was diese neuen WebAuthn Client-Fähigkeiten konkret für Ihre App bedeuten und wie Sie sie am besten nutzen. Hier sind ein paar Praxisempfehlungen.

Beachten Sie jedoch, dass Stand November 2024 noch nicht alle Browser den API-Aufruf getClientCapabilities() unterstützen. Es gibt ein Polyfill hier, das Sie als Zwischenlösung nutzen können.

Nutzen Sie getClientCapabilities() früh in Ihrem Code, idealerweise direkt beim Laden der Seite oder zu Beginn des Authentifizierungsablaufs. So können Sie das Erlebnis dynamisch anpassen und genau die Passkey-Features anbieten, die auf dem jeweiligen Gerät oder Browser funktionieren (z. B. Bevorzugung von Plattform-Authentifizierung oder Anbieten von Hardware Security Keys, falls nötig).

Wenn Sie Passkeys in eine App oder Website integrieren, die derzeit Passwörter verwendet, ist conditionalCreate ein echter Booster für Ihre Passkey-Adoption. Im Hintergrund wird während eines Passwort-Autofills mit einem passenden Credential Manager (Stand Oktober 2024 nur Apple Passwords) automatisch ein Passkey generiert, der künftig bevorzugt wird.

Um nicht nur eine hohe Passkey-Adoption, sondern auch eine hohe Passkey-Login-Nutzung zu erreichen, prüfen Sie mittels conditionalGet, ob das Gerät oder der Browser Conditional UI / Passkey-Autofill unterstützt. Dadurch werden Nutzer sanft dazu animiert, den erstellten Passkey für Logins zu verwenden, da er vom Betriebssystem proaktiv vorgeschlagen wird – das ist sogar noch müheloser als das automatische Ausfüllen eines Passworts.

Setzen Sie hybridTransport ein, um Cross-Device-Authentifizierung (via QR-Code und Bluetooth) zu ermöglichen. So können sich Nutzer nahtlos über ihr Smartphone anmelden, auch wenn sie Ihren Dienst gerade auf einem Desktop-Gerät aufrufen.

Die WebAuthn Client-Fähigkeiten sind ein wichtiger Schritt, um bestehende Lücken in der Passkey-Technologie zu schließen. In diesem Blogpost haben wir folgende Kernfragen beleuchtet:

1. Was sind WebAuthn Client-Fähigkeiten? Wir haben erklärt, wie Browser und Plattformen ihre Unterstützung für bestimmte Funktionen signalisieren können, was Entwicklern mehr Kontrolle gibt.
2. Welche WebAuthn Client-Fähigkeiten gibt es? Wir gaben einen Überblick über Neuerungen wie getClientCapabilities, conditionalCreate, hybridTransport und mehr.
3. Wie verbessern sie Passkey-Implementierungen? Die neuen Features optimieren die Integration, verbessern die geräteübergreifende Nutzung und erhöhen die Sicherheit.
4. Warum sind sie für Entwickler wichtig? Diese Funktionen helfen dabei, nahtlose und sichere Logins zu schaffen, die den Erwartungen moderner Nutzer entsprechen.

Wir empfehlen Ihnen, sich mit den neuen WebAuthn Level 3 Features vertraut zu machen und deren Adoption im Blick zu behalten. Wenn Sie Passkeys implementieren und diese fortgeschrittenen Möglichkeiten nutzen möchten, kontaktieren Sie uns für fachkundige Beratung und Unterstützung.

Rufen Sie getClientCapabilities() frühzeitig beim Laden der Seite oder im Login-Flow auf, um unterstützte Funktionen dynamisch zu erkennen. Dadurch können Sie Plattform-Authentifizierung anbieten, wenn sie unterstützt wird, oder auf Alternativen wie SMS-OTPs oder Hardware Security Keys zurückgreifen, wenn dies nicht der Fall ist.

signalAllAcceptedCredentials erfordert die vollständige Liste der gültigen Credential IDs sowie das WebAuthn User Handle. Es sollte daher nur aufgerufen werden, wenn der Nutzer bereits authentifiziert ist, um Privacy Leaks zu vermeiden. signalUnknownCredential signalisiert eine einzelne, nicht erkannte Credential ID, ohne die gesamte Liste zu benötigen. Dadurch ist es sicher in nicht-authentifizierten Szenarien nutzbar, etwa nach einem fehlgeschlagenen Login-Versuch.

Die Fähigkeit relatedOrigins ermöglicht eine reibungslose Authentifizierung über verschiedene Domains hinweg, die zur selben Organisation gehören (z. B. amazon.com und amazon.de). Nutzer können sich einmal einloggen und auf alle Bereiche zugreifen, ohne sich auf jeder Domain neu zu authentifizieren. Das reduziert Reibungsverluste in internationalen oder Multi-Service-Umgebungen.

Da Stand November 2024 noch nicht alle Browser getClientCapabilities() unterstützen, können Sie das Polyfill unter github.com/MasterKale/webauthn-polyfills als Zwischenlösung nutzen. Es ist zu erwarten, dass sich die Adaption beschleunigt, sobald der WebAuthn Level 3 Standard weiter ausgereift ist; Chrome 133, Edge 133, Firefox 135 und Safari 17.4 bieten bereits entsprechenden Support.