WebAuthn Client-Fähigkeiten

WebAuthn ist der moderne Standard hinter Passkeys. Anstatt auf herkömmliche Passwörter zu setzen, nutzt er Public-Key-Kryptografie. Dies ermöglicht es Usern, sich mit Passkeys zu authentifizieren, die biometrische Daten (wie Fingerabdrücke oder Gesichtserkennung) oder physische Sicherheitsschlüssel umfassen können. Dieser Wandel erhöht nicht nur die Sicherheit, sondern verbessert auch die User Experience, da die Passwortverwaltung entfällt.

Der WebAuthn Level 3-Standard führt neue Client-Fähigkeiten ein (die über die Browser-API getClientCapabilities() abgerufen werden können). Diese sollen Entwicklern und Plattformen mehr Kontrolle und Flexibilität bei der Implementierung von Passkeys geben. Die Neuerungen bringen Verbesserungen, die den Prozess der Integration von Passkeys über Geräte, Browser und Plattformen hinweg vereinfachen und so für eine reibungslosere und konsistentere User Journey sorgen.

In diesem Blogbeitrag beantworten wir die folgenden Fragen:

1. Was sind WebAuthn Client-Fähigkeiten?
2. Welche WebAuthn Client-Fähigkeiten gibt es?
3. Wie verbessern WebAuthn Client-Fähigkeiten die Implementierung von Passkeys?
4. Warum sind WebAuthn Client-Fähigkeiten sowohl für Entwickler als auch für Produktmanager wichtig?

Am Ende werden Sie verstehen, wie diese Funktionen Ihnen helfen können, nahtlose und sichere Authentifizierungsabläufe zu schaffen, die den modernen Erwartungen der User entsprechen.

WebAuthn Client-Fähigkeiten sind eine Reihe von Funktionen, die es Browsern und Plattformen ermöglichen, zu kommunizieren, welche Arten von WebAuthn-Funktionalitäten sie unterstützen. Einfach ausgedrückt, fungieren sie wie eine „Funktions-Checkliste“, die Websites darüber informiert, welche Authentifizierungsmethoden und Einstellungen auf dem Gerät eines Users verfügbar sind. Dies ermöglicht es Entwicklern, Authentifizierungsabläufe basierend auf den Fähigkeiten des Clients anzupassen und so eine reibungslosere und sicherere User Experience zu gewährleisten.

Wenn ein Browser beispielsweise signalisiert, dass er die biometrische Authentifizierung (wie Touch ID) unterstützt, können Entwickler ihre Anmeldeabläufe so gestalten, dass sie den Usern die Möglichkeit bieten, sich mit einem Fingerabdruck anzumelden. Wenn der Browser bestimmte Funktionen nicht unterstützt, können Entwickler umgekehrt Fallback-Optionen wie ein Passwort oder ein SMS-OTP anbieten.

Der WebAuthn Level 3-Standard führt mehrere neue Client-Fähigkeiten ein, die die Implementierung von Passkeys vielseitiger und benutzerfreundlicher machen. Die erste Unterstützung für den API-Aufruf getClientCapabilities() wurde in Safari 17.4 eingeführt.

Um die Unterstützung im Browser zu erkennen, kann das folgende Snippet nützlich sein:

// Check if PublicKeyCredential is supported in the current browser
if (typeof PublicKeyCredential === "undefined") {
    console.log("PublicKeyCredential is not supported in this browser.");
}
 
// Check if getClientCapabilities method exists on PublicKeyCredential
if (typeof PublicKeyCredential.getClientCapabilities === "function") {
    try {
        let capabilities = await PublicKeyCredential.getClientCapabilities();
        console.log(capabilities);
    } catch (error) {
        console.error("Error getting client capabilities:", error);
    }
} else {
    console.log("getClientCapabilities is not supported in this browser");
}

getClientCapabilities() ermöglicht es Websites und Apps, den Client (z. B. Browser oder Gerät) abzufragen, um festzustellen, welche WebAuthn-Funktionen er unterstützt. Durch das Verständnis der Fähigkeiten des Clients können Entwickler Authentifizierungsabläufe optimieren, um verfügbare Funktionen wie die biometrische Authentifizierung zu nutzen und alternative Methoden bereitzustellen, wenn bestimmte Fähigkeiten fehlen.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Werfen wir einen genaueren Blick auf die WebAuthn Client-Fähigkeiten und wie sie die Passkey-Integration beeinflussen:

conditionalCreate ermöglicht die automatische Erstellung von Passkeys unter bestimmten Bedingungen. Eine Anwendung könnte diese Fähigkeit nutzen, um während des Passwort-Autofills automatisch einen Passkey zu erstellen, wenn der Passwort-Manager die entsprechende Unterstützung bietet. Diese Funktion hilft, die Akzeptanz von Passkeys und deren anschließende Nutzung zu fördern, indem sie User automatisch von Passwörtern auf Passkeys umstellt.

Ähnlich wie conditionalCreate löst conditionalGet Passkey-Logins automatisch aus. Dies ist in Szenarien nützlich, in denen die beste Passkey-UX ermöglicht werden soll, wodurch der Login nicht nur passwortlos, sondern auch benutzernamenlos wird (User klicken einfach auf den ausgewählten Passkey in einem Modal/Dropdown und können sich authentifizieren). Durch die Nutzung dieser Fähigkeit können Entwickler sicherstellen, dass die Passkey-Authentifizierung nur dann stattfindet, wenn es angebracht ist, was unnötige Abfragen minimiert und die User Experience verbessert.

hybridTransport stellt sicher, dass Passkeys über verschiedene Geräte hinweg verwendet werden können, und ermöglicht eine nahtlose geräteübergreifende Authentifizierung (über QR-Codes und Bluetooth). Beispielsweise könnte ein User einen auf seinem Smartphone gespeicherten Passkey verwenden, um sich bei einem Dienst auf seinem Desktop anzumelden. Diese Fähigkeit ermöglicht es Usern, sich sicher zu authentifizieren, ohne Passkeys manuell übertragen oder sich auf herkömmliche Anmeldemethoden für jedes Gerät verlassen zu müssen, was ein einheitliches Authentifizierungserlebnis fördert.

Plattform-Authenticators wie Windows Hello, Face ID oder Touch ID sind direkt in die Geräte integriert und bieten ein schnelleres, reibungsloseres und sichereres Passkey-Erlebnis, indem sie es den Usern ermöglichen, sich mit Biometrie oder anderen geräteeigenen Methoden (z. B. PIN-Muster) zu authentifizieren.

Become part of our Passkeys Community for updates & support.

Join

userVerifyingPlatformAuthenticator stellt sicher, dass die Passkey-Authentifizierung eine User-Verifizierung beinhaltet, wie z. B. einen aktiven Fingerabdruck-Scan oder eine Gesichtserkennung, was eine zusätzliche Sicherheitsebene bietet.

Die Fähigkeit relatedOrigins ermöglicht eine nahtlose Authentifizierung über verschiedene Domains, die derselben Organisation gehören (z. B. amazon.com und amazon.de). Wenn ein Unternehmen beispielsweise mehrere Domains verwaltet oder verschiedene Subdomains hat, können sich User einmal anmelden und auf alle Angebote zugreifen, ohne sich bei jedem erneut authentifizieren zu müssen. Diese Fähigkeit optimiert die User Experience, reduziert Reibungsverluste und ist besonders wertvoll für Unternehmen in internationalen Umgebungen oder mit Multi-Service-Plattformen.

Die Methode signalAllAcceptedCredentials(options) liefert die vollständige Liste der WebAuthn Credential-IDs für einen bestimmten User. WebAuthn Relying Parties sollten diese Methode anstelle von signalUnknownCredential() verwenden, wenn der User authentifiziert ist, da kein Risiko eines Datenschutzlecks besteht. Diese Methode bietet einen umfassenden Überblick über die Public-Key-Credentials eines Users, einschließlich aller jüngsten Änderungen, die möglicherweise auf den aktuell verbundenen Authenticators noch nicht aktualisiert wurden.

Schauen wir uns ein Beispiel an. Ein User (userId: A) hat 2 Passkeys mit Credential-IDs, die Base64URL-kodiert X und Y ergeben. Dann löscht der User den Passkey X in den Kontoeinstellungen des Webdienstes (example.com) (der Public Key wird also gelöscht). Führen Sie nun das folgende Snippet aus:

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

Wenn der Authenticator zum Zeitpunkt der Ausführung des obigen Codes verfügbar ist, löscht oder verbirgt der Authenticator den Passkey X bei zukünftigen Authentifizierungszeremonien. Der Authenticator ist jedoch möglicherweise zum Zeitpunkt der Ausführung nicht angeschlossen, daher wird empfohlen, dass Relying Parties diesen Code regelmäßig ausführen, z. B. bei jeder Anmeldung.

Passkeys, die nicht in allAcceptedCredentialIds vorhanden sind, werden entfernt oder verborgen, möglicherweise unwiderruflich. Daher ist es wichtig, dass Relying Parties darauf achten, dass gültige WebAuthn Credential-IDs niemals aus der Liste entfernt werden. Wenn eine gültige Credential-ID versehentlich entfernt wurde, sollte die Relying Party sie so schnell wie möglich in einen weiteren signalAllAcceptedCredentials(options)-Aufruf aufnehmen, um den Passkey wieder „sichtbar“ zu machen. Wenn der Passkey nicht verborgen, sondern entfernt wurde, gibt es nicht viel, was man tun kann, um das Problem zu beheben.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

Die Methode signalCurrentUserDetails(options) signalisiert den aktuellen Namen und den WebAuthn Display Name des Users. Wenn signalCurrentUserDetails(options) aufgerufen wird, folgt der Client einer Reihe definierter Schritte, um diese Aktion auszuführen.

Sehen wir uns ein Beispiel an. Ein User mit der WebAuthn User-ID A aktualisiert seinen Namen in den Kontoeinstellungen einer Website (example.com). Dann kann die Relying Party den folgenden Code ausführen:

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "A", // user ID, Base64URL.
    name: "New user name",
    displayName: "New display name",
});

Der Authenticator würde dann die Metadaten des lokal gespeicherten Passkeys aktualisieren. Der große Vorteil ist, dass bei zukünftigen Conditional UI / Passkey-Autofill-Anfragen das Auswahl-/Dropdown-Menü der Conditional UI den aktualisierten Namen und WebAuthn Display Name anzeigt.

Die Methode signalUnknownCredential(options) signalisiert, dass eine WebAuthn Credential-ID von der WebAuthn Relying Party nicht erkannt wird, zum Beispiel, wenn der Passkey vom User gelöscht wurde. Im Gegensatz zu signalAllAcceptedCredentials(options) erfordert diese Methode nicht die Angabe der vollständigen Liste der akzeptierten Credential-IDs und des WebAuthn User-Handles, wodurch potenzielle Datenschutzlecks bei nicht authentifizierten Aufrufern verhindert werden.

Sehen wir uns ein Beispiel an. Ein User löscht einen Passkey mit der Credential-ID X in den Kontoeinstellungen einer Website (example.com) (der Public Key wird also gelöscht). Der Private Key ist jedoch weiterhin auf dem Gerät des Users verfügbar. Das bedeutet, dass bei zukünftigen Conditional UI / Passkey-Autofill-Login-Anfragen (mit einer leeren allowCredentials-Liste) der Passkey weiterhin ausgewählt werden kann. Der Anmeldeversuch 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 the user just tried, Base64URL
});

Der Authenticator würde dann den Passkey mit der Credential-ID X bei zukünftigen Authentifizierungszeremonien löschen oder verbergen.

Da sich der WebAuthn Level 3-Standard noch im Entwurfsstatus befindet, ist die Einführung dieser neuen Client-Fähigkeiten noch nicht vollständig verbreitet. Verschiedene Browser haben diese Funktionen schrittweise implementiert, aber die Unterstützung variiert. Unten finden Sie eine aktualisierte Übersicht über die Verfügbarkeit in den oben genannten großen Browsern:

Das Tempo der Einführung wird sich wahrscheinlich beschleunigen, wenn Level 3 ausgereift ist und mehr Browser diese Funktionen ausliefern. Wenn Sie sehen möchten, wie viele User getClientCapabilities() bereits jetzt nutzen können, können Sie reale Daten mit dem kostenlosen Passkeys Analyzer überprüfen. Behalten Sie die Versionshinweise der Browser und die relevante Dokumentation im Auge, um eine breitere Kompatibilität zu planen, sobald sie sich entwickelt.

Are your users passkey-ready?

Test Passkey-Readiness

Als Entwickler fragen Sie sich vielleicht, was diese neue Erkennung von WebAuthn Client-Fähigkeiten für Sie bedeutet und wie Sie sie in Ihrer App verwenden sollten. Im Folgenden finden Sie Empfehlungen für deren Nutzung.

Beachten Sie jedoch, dass (Stand November 2024) noch nicht alle Browser den API-Aufruf getClientCapabilities() unterstützen. Es gibt ein Polyfill, das hier verfügbar ist und verwendet werden kann, bis alle Browser aufgeholt haben.

Verwenden Sie getClientCapabilities() frühzeitig in Ihrem Code, um die unterstützten Funktionen des Clients zu Beginn des Seitenlade-/Authentifizierungsflusses zu erkennen. Dies ermöglicht es Ihnen, das Erlebnis dynamisch anzupassen und die Passkey-Funktionen bereitzustellen, die auf dem Gerät/Browser funktionieren, z. B. die Plattform-Authentifizierung zu fördern, wenn sie unterstützt wird, oder alternative Methoden (z. B. SMS-OTPs oder Hardware-Sicherheitsschlüssel) anzubieten, wenn nicht.

Wenn Sie Passkeys zu einer Website/App hinzufügen, die derzeit Passwörter verwendet, kann die Funktion conditionalCreate ein echter Booster für Ihre Passkey-Akzeptanz sein. Im Hintergrund wird während eines Passwort-Autofills mit einem geeigneten Credential-Manager (Stand Oktober 2024 nur Apple Passwords) automatisch ein Passkey generiert und bei zukünftigen Autofills bevorzugt.

Um nicht nur eine hohe Passkey-Akzeptanz, sondern auch eine hohe Nutzung von Passkey-Logins zu erreichen, versuchen Sie zu prüfen, ob das Gerät/der Browser Conditional UI / Passkey Autofill verwenden kann, indem Sie auf conditionalGet prüfen. Auf diese Weise werden Sie die User dazu anregen, den erstellten Passkey für Logins zu verwenden, da er proaktiv vom Betriebssystem/Browser vorgeschlagen wird und noch weniger Aufwand erfordert als das automatische Ausfüllen eines Passworts.

Nutzen Sie hybridTransport, um die geräteübergreifende Authentifizierung (über QR-Code und Bluetooth) zu ermöglichen. So können sich User nahtlos von ihrem Smartphone aus anmelden, auch wenn sie auf Ihren Dienst auf einem Desktop zugreifen.

WebAuthn Client-Fähigkeiten stellen einen bedeutenden Fortschritt dar, um bestehende Lücken bei Passkeys zu schließen. In diesem Blogbeitrag haben wir die wichtigsten Fragen zu den WebAuthn Client-Fähigkeiten beantwortet:

1. Was sind WebAuthn Client-Fähigkeiten? Wir haben erklärt, wie diese Funktionen es Browsern und Plattformen ermöglichen, ihre Unterstützung für bestimmte Funktionalitäten zu signalisieren, was Entwicklern mehr Kontrolle über Authentifizierungsabläufe gibt.
2. Welche WebAuthn Client-Fähigkeiten gibt es? Wir haben einen Überblick über die neuen Fähigkeiten gegeben, die im Level-3-Standard eingeführt wurden, einschließlich getClientCapabilities, conditionalCreate, hybridTransport und mehr.
3. Wie verbessern WebAuthn Client-Fähigkeiten die Implementierung von Passkeys? Wir haben erörtert, wie diese Fähigkeiten die Integration optimieren, die geräteübergreifende Nutzung verbessern und die Sicherheit erhöhen.
4. Warum sind WebAuthn Client-Fähigkeiten für Entwickler wichtig? Diese Funktionen helfen dabei, nahtlose und sichere Authentifizierungserlebnisse zu schaffen, die den modernen Erwartungen der User entsprechen, was die Implementierung einfacher und effektiver macht.

Wir ermutigen Sie, die neuen WebAuthn Level 3-Funktionen zu erkunden und sich über deren Einführung in den verschiedenen Browsern auf dem Laufenden zu halten. Wenn Sie Passkeys implementieren und diese fortschrittlichen Fähigkeiten nutzen möchten, kontaktieren Sie uns für fachkundige Beratung und Unterstützung.