WebAuthn Conditional UI (Passkey-Autofill): Eine technische Erklärung

Passkeys-Cheatsheet. Praxisnahe Leitfäden, Rollout-Muster und KPIs für Passkey-Programme.

Cheat Sheet erhalten

Mit der schnellen Akzeptanz von Passkeys (und dem zugrunde liegenden WebAuthn-Protokoll) ist die Authentifizierung für viele Nutzer sicherer und benutzerfreundlicher geworden. Einer der herausragenden Fortschritte von Passkeys ist die Integration von Conditional UI, oft als "Passkey-Autofill" oder Conditional Mediation bezeichnet (im Folgenden bleiben wir beim Begriff Conditional UI).

Trotz der jüngsten Einführung und der fortlaufenden Übernahme durch Browser gibt es eine spürbare Lücke bei technischen Dokumentationen und Implementierungshinweisen für Conditional UI. Dieser Artikel soll diese Lücke schließen, indem er erklärt, was Conditional UI ist, wie es funktioniert und wie man häufige Herausforderungen bei der Implementierung meistert.

Conditional UI stellt einen neuen Modus für Passkey- / WebAuthn-Anmeldeprozesse dar. Es zeigt Passkeys selektiv in einer Benutzeroberfläche (UI) an, aber nur dann, wenn ein Nutzer ein Discoverable Credential (Resident Key) – eine Art von Passkey –, das bei der Relying Party (dem Online-Dienst) registriert ist, im Authentifikator eines Geräts (z. B. Laptop, Smartphone) gespeichert hat. Die Passkeys werden in einem Auswahl-Dropdown-Menü angezeigt, das mit automatisch ausgefüllten Passwörtern gemischt ist, und bieten einen nahtlosen Übergang zwischen traditionellen Passwortsystemen und fortschrittlicher Passkey-Authentifizierung, da Nutzer beides im gleichen Kontext sehen. Dieser intelligente Ansatz stellt sicher, dass Nutzer nicht mit unnötigen Optionen überfordert werden und den Anmeldeprozess reibungsloser durchlaufen können.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

Die Grundlage von Conditional UI baut auf drei Hauptpfeilern auf:

1. Nutzerdatenschutz respektieren: Sicherstellung des Datenschutzes, indem die Offenlegung verfügbarer Credentials oder fehlende Nutzereinwilligungen zur Offenlegung dieser Credentials verhindert werden.
2. Großartige Nutzererfahrung, auch wenn kein Passkey existiert: Relying Parties zu befähigen, WebAuthn opportunistisch zu implementieren, um sicherzustellen, dass die Nutzererfahrung gut bleibt, auch wenn keine Passkeys verfügbar sind.
3. Reibungsloser Übergang von Passwörtern zu Passkeys: Kombination von Passkeys mit passwortbasierter Authentifizierung, um den Übergang zu passwortlosen Authentifizierungsmethoden zu erleichtern und aus den vertrauten UX-Paradigmen der Nutzer Kapital zu schlagen.

• Optimierte Authentifizierung: Der Prozess ist optimierter und effizienter und beseitigt die Komplexitäten, die oft mit mehreren Authentifizierungsmethoden verbunden sind.
• Reduzierung von Nutzerfehlern: Durch die Präsentation nur relevanter Optionen ist es weniger wahrscheinlich, dass Nutzer Fehler während des Authentifizierungsprozesses machen.
• Erhöhte Nutzerzufriedenheit: Das Entfernen unnötiger Schritte bedeutet, dass sich Nutzer schneller und müheloser anmelden können, was zu einer verbesserten Nutzerzufriedenheit führt.
• Einfache Frontend-Integration: Eines der herausragenden Merkmale von Conditional UI ist seine einfache Integration. Entwickler können es nahtlos in das Frontend einbinden, mit nur wenigen Codezeilen (siehe unten).
• Passwortlose und nutzernamefreie Anmeldung: Einer der großen Vorteile ist, dass Conditional UI nicht nur die passwortlose Authentifizierung fördert, sondern auch eine nutzernamefreie oder konto-freie Erfahrung. Nutzern bleibt die mentale Belastung erspart, sich ihre spezifische E-Mail-Adresse oder ihr Nutzer-Handle von der Registrierung merken zu müssen. Stattdessen können sie sich auf die Vorschläge des Browsers verlassen, welche die E-Mail-Adresse/das Nutzer-Handle gepaart mit dem entsprechenden Passkey im Autofill-Menü enthalten.
• Lösung des Bootstrapping-Dilemmas: Der Übergang von traditionellen Nutzername-Passwort-Systemen zu Passkeys kann entmutigend sein. Conditional UI geht diese Übergangsherausforderung an. Websites können einen Passkey- / WebAuthn-Aufruf zusammen mit einer herkömmlichen Passwortabfrage initiieren, ohne sich über mögliche Fehler im modalen Dialogfeld Sorgen machen zu müssen, falls einem Gerät die benötigten Credentials fehlen.

Abonnieren Sie unseren Passkeys Substack für aktuelle News.

Abonnieren

• Lernkurve für Entwickler: Conditional UI führt ein neues Paradigma ein, was bedeutet, dass Entwickler, die mit den Details nicht vertraut sind, eine Lernkurve bewältigen müssen.
• Geräte- / Browser-Abhängigkeit: Der Erfolg von Conditional UI hängt von der Geräte- oder Browser-Kompatibilität des Nutzers ab. Da derzeit nicht alle Browser oder Geräte dies unterstützen, kann dies die Anwendung einschränken.
• Passwort-Manager deaktivieren Autocomplete: Einige moderne Passwort-Manager und deren Browser-Erweiterungen modifizieren das DOM der Websites und deaktivieren oder überschreiben das Autocomplete-Tag in Eingabefeldern zugunsten ihrer eigenen Autocomplete-Funktionen. Dies kann zu einer inkonsistenten und unbefriedigenden Nutzererfahrung führen. Da Standards für Conditional UI relativ neu sind, hoffen wir, dass sich die Dinge verbessern, sodass sich z. B. nicht zwei Autofill-Menüs überlagern oder das gewünschte gar nicht erst angezeigt wird.

Im Folgenden bieten wir eine schrittweise Aufschlüsselung der einzelnen Schritte eines gesamten Conditional UI-Prozesses:

Im Allgemeinen kann der Prozessablauf von Conditional UI in zwei Phasen unterteilt werden. Während der Seitenladephase läuft die Conditional UI-Logik im Hintergrund ab, während der Nutzer in der Nutzerbetriebsphase aktiv etwas tun muss.

1. Verfügbarkeitsprüfung für Conditional UI: Der Client (Browser) ruft die Funktion isConditionalMediationAvailable() auf, um zu erkennen, ob die aktuelle Browser- / Geräte-Kombination Conditional UI unterstützt. Nur wenn die Antwort true lautet, geht der Prozess weiter, andernfalls wird der Conditional UI-Prozess abgebrochen.
2. Aufruf des Conditional UI-Endpunkts: Als Nächstes ruft der Client den Conditional UI-Endpunkt des Servers auf, um die PublicKeyCredentialRequestOptions abzurufen.
3. Empfang der PublicKeyCredentialRequestOptions: Der Server gibt die PublicKeyCredentialRequestOptions zurück, die die Challenge und weitere WebAuthn-Serveroptionen (z. B. allowCredentials, extensions, userVerification) enthalten.
4. Start der lokalen Authentifizierung: Durch den Aufruf von credentials.get() mit den empfangenen PublicKeyCredentialRequestOptions und der Eigenschaft mediation, die auf conditional gesetzt ist, startet der Prozess für die lokale Authentifizierung auf dem Gerät.
5. Autofill-Auswahl anzeigen: Das Autofill-Menü für Passkeys wird geöffnet. Das spezifische Design hängt vom Browser und Gerät ab (z. B. erfordern einige, dass der Nutzer den Cursor in das Eingabefeld platziert, einige zeigen das Menü beim Laden der Seite automatisch an, siehe unten).
6. Lokale Nutzerauthentifizierung: Der Nutzer wählt den Passkey aus dem Autofill-Menü aus, den er verwenden möchte, und authentifiziert sich über den Authentifizierungsdialog seines Geräts (z. B. über Face ID, Touch ID, Windows Hello).
7. Authentifikator-Antwort an Server senden: Wenn die lokale Nutzerauthentifizierung erfolgreich war, wird die Authentifikator-Antwort zurück an den Server gesendet.
8. Nutzer ist angemeldet und wird weitergeleitet: Sobald der Server die Authentifikator-Antwort empfängt, validiert er die Signatur gegen den öffentlichen Schlüssel des entsprechenden Nutzerkontos in der Datenbank. Wenn die Überprüfung erfolgreich ist, erhält der Nutzer Zugriff, ist angemeldet und wird auf die Seite für angemeldete Nutzer weitergeleitet.

Durch Befolgung dieses Prozessablaufs bietet Conditional UI eine nahtlose und benutzerfreundliche Authentifizierungserfahrung.

Um Conditional UI zum Laufen zu bringen, müssen einige allgemeine Aspekte beachtet werden:

• Credential-Spezifikationen: Conditional UI ist speziell so konzipiert, dass es nur mit Resident Keys / Discoverable Credentials funktioniert. Der Grund dafür ist, dass Authentifikatoren keine nutzerspezifischen Daten (z. B. Name, Anzeigename) für Non-Resident Keys / Non-Discoverable Credentials speichern. Daher ist die Verwendung letzterer für Passkey-Autofill nicht möglich.
• Credential-Filterung: Die Funktion allowCredentials wird weiterhin unterstützt und erleichtert Websites, denen die Identität des Nutzers bereits bekannt ist (zum Beispiel, wenn ein Nutzername im anfänglichen Mediation-Aufruf gesendet wurde, weil er möglicherweise im LocalStorage des Browsers gespeichert ist), die Liste der Credentials einzugrenzen, die Nutzern beim Autofill präsentiert werden.

Werden Sie Teil unserer Passkeys Community für Updates und Support.

Beitreten

Um Conditional UI auf der Clientseite zum Laufen zu bringen, müssen folgende Anforderungen erfüllt sein:

• Kompatibler Browser: Stellen Sie sicher, dass der Nutzer einen modernen Browser verwendet, der Conditional UI unterstützt (siehe hier für die aktuelle Browser-Abdeckung).
• Aktiviertes JavaScript: JavaScript muss aktiviert sein, um Conditional UI-Operationen zu erleichtern.
• Verfügbarkeit von Conditional UI testen: Die Relying Party (die Serverseite) sollte Gewissheit haben, dass Conditional UI auf der Clientseite verfügbar ist, wenn sie den WebAuthn-Mediation-Aufruf empfängt, um das Auslösen nutzersichtbarer Fehler in Szenarien zu vermeiden, in denen Conditional UI nicht unterstützt wird. Um dies anzugehen, wird empfohlen, die Methode isConditionalMediationAvailable() zu verwenden und die technische Verfügbarkeit von Conditional UI zu prüfen (siehe unten für weitere Details).
• HTML-Eingabefeld erforderlich: Damit Conditional UI funktioniert, müssen Sie ein HTML-Eingabefeld in Ihrer Webseite haben. Wenn Sie keines haben, müssen Sie Unterstützung für den regulären Passkey- / WebAuthn-Anmeldeprozess bieten, der durch eine Nutzerinteraktion ausgelöst wird, wie einen Klick auf eine Schaltfläche.
• Timeout-Protokolle entfernen: Timeout-Parameter (z. B. der Nutzer braucht sehr lange, um sich für einen Passkey im Autofill-Menü zu entscheiden) sollten in diesem Setup ignoriert werden.

Um Conditional UI zum Laufen zu bringen, müssen auch auf der Serverseite einige Anforderungen erfüllt sein:

• Laufender WebAuthn-Server: Da wir uns immer noch im Kontext von Passkeys / WebAuthn befinden, ist es erforderlich, einen laufenden WebAuthn-Server zu haben, der die Authentifizierungsverfahren verwaltet.
• Bereitstellung des Endpunkts für den Mediation-Start: Im Vergleich zu regulären WebAuthn-Login-Endpunkten ist es nützlich, einen weiteren Endpunkt bereitzustellen, der eine ähnliche Funktionalität hat, aber mit einem optionalen Nutzer-Handle (z. B. E-Mail-Adresse, Telefonnummer, Nutzername) umgehen kann.

Seit der offiziellen Einführung von Conditional UI Ende 2022 und früheren Beta-Versionen haben wir es ausführlich getestet und damit gearbeitet. Im Folgenden möchten wir Ihnen praktische Tipps geben, die während der Implementierung von Conditional UI geholfen haben.

Experimentieren Sie mit Passkey-Flows im Passkeys Debugger.

Kostenlos testen

Ein vollständiges, minimalistisches Codebeispiel für eine Conditional UI-Methode würde so aussehen:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // retrieve the request options (incl. the challenge) from the WebAuthn server
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

Implementieren Sie eine Conditional UI-Erkennung, die sicherstellt, dass Conditional UI nur dann verwendet wird, wenn die aktuelle Geräte- / Browser-Kombination dies unterstützt. Dies sollte funktionieren, ohne nutzersichtbare Fehler bei fehlender Conditional UI-Unterstützung anzuzeigen. Die Einbindung der Methode isConditionalMediationAvailable() innerhalb der Benutzeroberfläche adressiert dieses Anliegen. Wenn Conditional UI-Unterstützung gegeben ist, kann der Conditional UI-Anmeldeprozess gestartet werden.

// source: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/isConditionalMediationAvailable#examples
 
// Availability of `window.PublicKeyCredential` means WebAuthn is usable.
if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) {
    // Check if conditional mediation is available.
    const isCMA = await PublicKeyCredential.isConditionalMediationAvailable();
    if (isCMA) {
        // Call WebAuthn authentication start endpoint
 
        let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
        const credential = await navigator.credentials.get({
            publicKey: options.publicKeyCredentialRequestOptions,
            mediation: "conditional",
        });
        /*
        ...
        */
    }
}

Das Eingabefeld sollte ein HTML-Autofill-Token für WebAuthn erhalten. Dies signalisiert dem Client, Passkeys in die laufende Anfrage zu füllen. Neben Passkeys könnten auch andere Autofill-Werte angezeigt werden. Diese Autofill-Tokens können mit anderen vorhandenen Tokens kombiniert werden, z. B.:

• autocomplete="username webauthn": Neben der Anzeige von Passkeys wird auch der Nutzername für Autofill vorgeschlagen.
• autocomplete="current-password webauthn": Neben der Anzeige von Passkeys wird weiter zum Ausfüllen des Passworts aufgefordert.

<label for="name">Username:</label>
<input type="text" name="name" autocomplete="username webauthn" />
<label for="password">Password:</label>
<input type="password" name="password" autocomplete="current-password webauthn" />

Für weitere Details empfehlen wir, diesen Blogbeitrag zu lesen, der weitere Details zu Autofill- / Autocomplete-Tokens für Passkeys und Passwörter enthält.

Um verfügbare Passkeys nach Erhalt des Objekts PublicKeyCredentialRequestOptions abzurufen, sollte die Funktion navigator.credentials.get() aufgerufen werden (die sowohl Passkeys als auch Passwörter bedient). Das Objekt PublicKeyCredentialRequestOptions muss den Parameter mediation auf conditional gesetzt haben, um Conditional UI auf dem Client zu aktivieren. Für Fälle, in denen Sie stattdessen eine modale Passkey-Aufforderung wünschen, sehen Sie sich die sofortige Mediation an.

const credential = await navigator.credentials.get({
    publicKey: options.publicKeyCredentialRequestOptions,
    mediation: "conditional",
});

Wenn kein Passkey verfügbar ist oder der Nutzer die vorgeschlagenen Passkeys ignoriert und seine E-Mail-Adresse eingibt, wird der Conditional UI-Prozess gestoppt. Dies unterstreicht die Wichtigkeit, immer auch die Standard-Passkey- / WebAuthn-Anmeldung über ein Modal zu unterstützen.

Ein wichtiger Punkt, der hier betont werden muss, ist die potenzielle Notwendigkeit, eine laufende Conditional UI-Anfrage anzuhalten. Im Gegensatz zu modalen Erlebnissen fehlen Autofill-Dropdowns eine Abbrechen-Schaltfläche. Nach dem Design von WebAuthn sollte zu einem bestimmten Zeitpunkt nur eine einzige aktive Credential-Anfrage im Gange sein. Der WebAuthn-Standard schlägt die Verwendung eines AbortControllers vor, um einen WebAuthn-Prozess abzubrechen, was sowohl für reguläre als auch für Conditional UI-Anmeldeprozesse gilt (siehe hier für Details).

In der Produktionstelemetrie ist dieser Abbruchpfad oft ein erwartetes Kontrollfluss-Ergebnis, kein Systemausfall. Wenn Sie ein hohes Fehlervolumen sehen, müssen Sie die erwarteten gegenüber den unerwarteten Fällen nach Vorgangsart und Timing klassifizieren, bevor Sie sie als Regressionen behandeln (siehe WebAuthn-Fehler).

Der Conditional UI-Anmeldeprozess wird aktiviert, sobald ein Nutzer auf der Seite landet. Die erste Aufgabe sollte darin bestehen, ein global skopiertes AbortController-Objekt zu erstellen. Dies dient als Signal für Ihren Client, die Autofill-Anfrage zu beenden, insbesondere wenn der Nutzer entscheidet, den regulären Passkey-Anmeldeprozess durchzuführen. Stellen Sie sicher, dass der AbortController von anderen Funktionen aufgerufen werden kann und zurückgesetzt wird, wenn der Conditional UI-Prozess neu gestartet werden muss. Verwenden Sie die Eigenschaft signal innerhalb des Aufrufs navigator.credentials.get() und integrieren Sie Ihr AbortController-Signal als ihren Wert. Dies signalisiert der Passkey- / WebAuthn-Funktion, dass die Anfrage gestoppt werden muss, falls das Signal abgebrochen wird. Denken Sie daran, jedes Mal einen neuen AbortController einzurichten, wenn Sie Conditional UI auslösen. Die Verwendung eines bereits abgebrochenen AbortControllers führt zu einem sofortigen Abbruch der Passkey- / WebAuthn-Funktion. Die restlichen Schritte entsprechen einem regulären Passkey-Anmeldeprozess. Im Folgenden sehen Sie ein Codebeispiel der genannten Schritte:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // retrieve the request options (incl. the challenge) from the WebAuthn server
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

Wenn Conditional UI nicht unterstützt wird, leiten Sie Nutzer zum regulären Passkey-Anmeldeprozess weiter. Das Anbieten dieses Pfades ist wichtig für Nutzer, die sich auf Hardware-Sicherheitsschlüssel (z. B. YubiKeys) verlassen oder gezwungen sind, Non-Resident Keys / Non-Discoverable Credentials aufgrund von Authentifikator-Beschränkungen zu verwenden.

Sehen Sie, wie viele Menschen Passkeys tatsächlich nutzen.

Adoptionsdaten ansehen

Wenn Sie eine native App entwickeln, z. B. für iOS oder Android, funktioniert Conditional UI ebenfalls. Es spielt keine Rolle, ob Sie es nativ in Flutter, Kotlin oder Swift implementieren, oder ob Sie sich für Chrome Custom Tabs (CCT) oder SFSafariViewController oder SFAuthenticationSession / ASWebAuthenticationSession entscheiden. Beide Ansätze unterstützen Conditional UI.

Generell haben wir fast keine Dokumentation darüber gefunden, wie man Conditional UI-Unterstützung für iOS-Apps implementiert. Während unserer Recherche haben wir jedoch zwei Möglichkeiten entdeckt, um einer iOS-App Conditional UI-Unterstützung hinzuzufügen, da sich auch das Nutzererlebnis unterscheiden wird.

Typ A: Overlay / Popup über fast den gesamten Bildschirm

Der erste Typ A zeigt ein Overlay / Popup an, das sich über fast den gesamten Bildschirm erstreckt. Hier sehen Sie alle verfügbaren Passkeys für diese Relying Party. Ein prominentes Beispiel, das Conditional UI auf diese Weise implementiert, ist KAYAK. Das Overlay / Popup erscheint automatisch, wenn der Nutzer den richtigen Bildschirm öffnet.

Typ B: Tastatur-Autofill

Der zweite Typ B zeigt einen passenden Passkey im Autofill-Bereich der Tastatur an (wo auch Passwörter für das automatische Ausfüllen vorgeschlagen werden). Durch Klicken auf den vorgeschlagenen Wert wird die Face ID-Authentifizierung durchgeführt und Sie können sich anmelden. In der aktuellen iOS-App-Version des Corbado-Entwickler-Panels haben wir dies auf diese Weise implementiert (siehe die Nachricht "Mit Passkey anmelden für <relying party ID>" zusammen mit dem WebAuthn-Nutzernamen). Um angezeigt zu werden, muss der Nutzer in das Eingabefeld tippen:

Diese Passkey-Autofill-Funktion im Tastaturbereich könnte Probleme aufweisen, wenn iOS frisch installiert ist, da scheinbar eine Art von Caching im Hintergrund abläuft, das alle verfügbaren Passkeys für diese Relying Party sucht.

Ein Klick auf das Schlüsselsymbol auf der rechten Seite des vorgeschlagenen Passkeys führt zur bekannten Seite für die Auswahl von Passwörtern / Passkeys in iOS:

Bitte beachten Sie, dass wir keine offizielle Dokumentation gefunden haben und unsere Erkenntnisse auf unseren Erfahrungen und Hypothesen beruhen, nicht auf konkreten Beweisen für die richtige Implementierung.

Bei Android ist die Geschichte für Conditional UI etwas klarer, da es nur einen Typ für Conditional UI / Passkey-Autofill gibt, der die Android Credential Manager API nutzt (siehe die Dokumentation hier). Weil Android-Anbieter variieren können, überwachen Sie Credential Manager-Passkey-Fehler getrennt von reinen Browser-WebAuthn-Fehlermustern.

Beim Öffnen der Seite, auf der Conditional UI implementiert ist, wird der folgende Bildschirm angezeigt, auf dem Sie verschiedene Möglichkeiten zur Anmeldung finden:

Ein Klick auf Weitere gespeicherte Anmeldedaten (More saved sign-ins) bietet weitere Optionen zur Auswahl für die Anmeldung (einschließlich geräteübergreifender Authentifizierung und der Auswahl einer anderen Passkey-Sync-Plattform, z. B. Samsung Pass oder 1Password):

Um zu veranschaulichen, wie Conditional UI für den Endnutzer aussieht, haben wir mehrere Screenshots eines Conditional UI-Autofill-Menüs unter Verwendung von https://passkeys.eu hinzugefügt.

Testen Sie Passkeys in einer Live-Demo.

Passkeys testen

Lassen Sie uns einige häufige Szenarien in realen Anwendungen betrachten.

Wenn kein Passkey für eine Website gespeichert ist, verhält sich das Conditional UI je nach Browser und Betriebssystem unterschiedlich.

In Chrome unter macOS zeigt ein Klick in das Eingabefeld ein leeres Autofill-Dropdown:

In Safari unter macOS wird kein Dropdown angezeigt – nur ein dezentes Symbol im Eingabefeld:

Unter Android oder iOS erscheint die Autofill-Oberfläche nur, wenn der Nutzer in das Feld tippt und das Betriebssystem passende Credentials findet.

Diese Variabilität ist beabsichtigt und Teil des Datenschutzmodells von WebAuthn: Websites können nicht erkennen, ob der Nutzer einen Passkey hat, es sei denn, der Nutzer wählt aktiv einen aus.

Wenn ein Nutzer mehrere Passkey-Anbieter installiert hat (z. B. iCloud-Schlüsselbund, Google Passwortmanager, 1Password), wählt der Browser oder das Betriebssystem in der Regel den primären Credential-Manager des Nutzers als Standard.

Für eine Liste verschiedener Passkey-Anbieter / Credential-Manager, die Passkeys unterstützen, empfehlen wir einen Blick auf den folgenden GitHub-Link.

Unter Android bietet der Credential Manager verschiedene Anbieter wie Samsung Pass oder 1Password.

1. Beim Klicken auf das Eingabefeld für den Nutzer-Identifikator öffnet sich dieses Menü, in dem der Nutzer einen Passkey auswählen kann.

2. Wenn der Nutzer auf dem vorherigen Bildschirm auf "Weitere Passkeys" geklickt hat, erscheint eine Vorauswahl an anderen Passkey-Anbietern / Credential-Managern und Passkeys:

3. Wenn der Nutzer auf dem vorherigen Bildschirm auf "Weitere gespeicherte Anmeldedaten" geklickt hat, erscheint eine vollständige Liste der verfügbaren Optionen, aus der der Nutzer einen Passkey auswählen kann.

Unter iOS öffnet das Schlüsselsymbol die vollständige Liste der Passkeys aus verschiedenen Quellen.

1. Zunächst wird unter iOS 18+ das reguläre Conditional UI mit dem Standard-Passkey-Anbieter angezeigt.

2. Beim Klicken auf das Tastatursymbol erscheint das folgende Auswahlmenü.

3. Nach Auswahl eines Credential-Managers / Passkey-Anbieters kann der Nutzer den zu verwendenden Passkey auswählen.

Passkeys, mit ihrer Conditional UI / Passkey-Autofill-Fähigkeit, sind der neue Weg zur Online-Authentifizierung. Da wir in eine Ära übergehen, in der Passwörter mehr und mehr durch Passkeys ersetzt werden, ist die Notwendigkeit von robusten und benutzerfreundlichen Übergangsmechanismen unbestreitbar. Dieser Artikel hat geholfen zu verstehen, wie man Conditional UI – eine große Hilfe im Übergangsprozess – richtig implementiert und auf welche Aspekte besonders zu achten ist.

Über Corbado

Corbado ist die Authentication Intelligence Platform für CIAM-Teams, die Consumer-Authentifizierung im großen Maßstab betreiben. Wir zeigen Ihnen, was IDP-Logs und generische Analytics-Tools nicht sehen können: welche Geräte, OS-Versionen, Browser und Credential-Manager Passkeys unterstützen, warum Enrollments nicht zu Logins werden, wo der WebAuthn-Flow scheitert und wann ein OS- oder Browser-Update den Login still und leise unterbricht – und das alles, ohne Okta, Auth0, Ping, Cognito oder Ihren In-House-IDP zu ersetzen. Zwei Produkte: Corbado Observe ergänzt Observability für Passkeys und jede andere Login-Methode. Corbado Connect bringt Managed Passkeys mit integrierter Analytics (neben Ihrem IDP). VicRoads betreibt Passkeys für über 5 Mio. Nutzer mit Corbado (+80 % Passkey-Aktivierung). Mit einem Passkey-Experten sprechen →

Rufen Sie PublicKeyCredential.isConditionalMediationAvailable() auf und fahren Sie nur fort, wenn es true zurückgibt. Diese Prüfung verhindert für den Nutzer sichtbare Fehler bei nicht unterstützten Browser- und Gerätekombinationen. Die Methode sollte bei jedem Seitenaufruf evaluiert werden, bevor navigator.credentials.get() mit mediation: "conditional" aufgerufen wird.

Authentifikatoren speichern nutzerspezifische Daten wie Name und Anzeigename nur für Resident Keys (Discoverable Credentials). Bei Non-Resident Keys werden diese Informationen nicht gespeichert, weshalb das Autofill-Menü keine Kontodetails zur Auswahl für den Nutzer füllen kann.

Das Verhalten variiert je nach Plattform. Chrome unter macOS zeigt ein leeres Autofill-Dropdown, Safari unter macOS zeigt nur ein dezentes Symbol im Eingabefeld, und unter Android oder iOS erscheint die Autofill-Oberfläche nur, wenn das Betriebssystem nach dem Tippen des Nutzers in das Feld passende Credentials findet. Diese Variabilität ist beabsichtigt und Teil des Datenschutzmodells von WebAuthn: Websites können nicht erkennen, ob ein Passkey existiert, es sei denn, der Nutzer wählt aktiv einen aus.

Erstellen Sie einen global skopierten AbortController und übergeben Sie dessen Signal an navigator.credentials.get(). Rufen Sie .abort() auf dem Controller auf, wenn der Nutzer einen modalen Login-Prozess startet. Instanziieren Sie bei jedem Neustart von Conditional UI einen neuen AbortController, da die Wiederverwendung eines bereits abgebrochenen Controllers zum sofortigen Abbruch der WebAuthn-Anfrage führt.

Conditional UI funktioniert sowohl in nativen iOS- als auch in Android-Apps. iOS unterstützt zwei Varianten: ein Vollbild-Overlay-Popup und einen Vorschlag zum Ausfüllen der Tastatur. Android verwendet die Credential Manager API, die Passkeys von mehreren Anbietern wie Samsung Pass oder 1Password anzeigen kann.