WebAuthn-Transports: Interner und hybrider Transport

Passkeys for Super Funds and Financial Institutions
Join our Webinar on 7th November to learn how Super Funds and Financial Institutions can implement passkeys

Join now

Hinweis: Gemäß der WebAuthn-Spezifikation bedeutet ein leeres Transports-Array, dass alle Transportarten unterstützt werden.

Bei der plattformübergreifenden Implementierung von Passkeys stehen Entwickler vor einer wichtigen Entscheidung:

• Wie sollte man mit WebAuthn-Transports umgehen, insbesondere mit internen und hybriden Transports, um eine optimale geräteübergreifende Authentifizierung zu gewährleisten?

Die Antwort liegt im Verständnis der WebAuthn-Transports – einem technischen Detail, das bestimmt, wie Authenticators mit Relying Parties kommunizieren. Obwohl Transports in der Theorie einfach erscheinen, variiert ihre Implementierung erheblich zwischen Webbrowsern, nativen iOS- und Android-Anwendungen, insbesondere im Umgang mit internen und hybriden Transports.

Dieser Artikel untersucht, wie WebAuthn-Transports auf verschiedenen Plattformen funktionieren, und stellt zwei unterschiedliche Ansätze für den Umgang mit internen und hybriden Transports vor – jeder mit seinen eigenen Kompromissen.

Dieser Artikel behandelt:

1. WebAuthn-Transports: intern, hybrid und Plattform-Authenticators im Web, auf iOS und Android
2. Zwei Ansätze: Spezifikationskonformer vs. optimierter Umgang mit internen und hybriden Transports
3. Best Practices und Empfehlungen für die Implementierung der geräteübergreifenden Authentifizierung

WebAuthn-Transports definieren die Kommunikationsmethoden zwischen Authenticators und Client-Geräten. Die WebAuthn Level 3 Spezifikation definiert sechs Transporttypen:

usb: Wird von Hardware-Sicherheitsschlüsseln verwendet, die über USB-Anschlüsse verbunden werden, wie z. B. YubiKeys oder andere FIDO2-Sicherheitstoken.

nfc: Ermöglicht die Kommunikation mit Authenticators über Near Field Communication, sodass Nutzer ihre Sicherheitsschlüssel oder NFC-fähigen Geräte antippen können.

ble: Erleichtert die Authentifizierung über Bluetooth Low Energy und ermöglicht die drahtlose Kommunikation mit externen Authenticators.

smart-card: Wird für Smartcard-Lesegeräte verwendet und ermöglicht die Authentifizierung über Smartcards.

hybrid: Ermöglicht die geräteübergreifende Authentifizierung, bei der ein Nutzer typischerweise einen QR-Code scannt, um sich über Geräte hinweg zu authentifizieren – z. B. mit einem Smartphone in einem Desktop-Browser oder umgekehrt. Dieser Transport kann QR-Code-Aufforderungen sowohl auf Desktop- als auch auf Mobilgeräten auslösen, was je nach Kontext nicht immer wünschenswert ist. Hinweis: hybrid wurde in WebAuthn Level 3 hinzugefügt.

internal: Der Authenticator ist in das Gerät selbst eingebettet – wie der iCloud-Schlüsselbund (verifiziert durch Face ID oder Touch ID) auf iPhones, Windows Hello auf PCs oder der Google Passwortmanager auf Android-Geräten. Dies sind Plattform-Authenticators.

Wenn ein Passkey erstellt wird, signalisiert der Authenticator, welche Transports er unterstützt. Diese Information wird an die Relying Party (Ihr Backend) gesendet, die sie zusammen mit den Anmeldeinformationen speichern sollte. Bei der Authentifizierung sendet die Relying Party diese Transports in der allowCredentials-Liste an den Client zurück, was dem Browser oder der Plattform hilft zu bestimmen, welche Authentifizierungsmethoden dem Nutzer angeboten werden sollen.

Der Umgang mit Transports unterscheidet sich erheblich zwischen den Plattformen, was zu den Kompatibilitätsproblemen führt, mit denen Entwickler konfrontiert sind.

Browser empfangen Transportinformationen von Authenticators und berücksichtigen diese bei Authentifizierungsabläufen. Wenn Sie einen Passkey erstellen in Chrome, Safari oder Edge, liefert der Credential Manager des Browsers Transportdaten, die je nach zugrunde liegendem Authenticator variieren:

Plattform-Authenticators: Windows Hello liefert nur ["internal"], was seine Gerätegebundenheit widerspiegelt. Wenn Chrome jedoch den Google Passwortmanager als Authenticator verwendet, liefert er ["internal", "hybrid"], da der Google Passwortmanager die geräteübergreifende Authentifizierung über Android-Telefone unterstützt.

Hardware-Sicherheitsschlüssel: Liefern spezifische Transports wie ["usb", "nfc"] basierend auf ihren tatsächlichen Fähigkeiten.

Cloud-synchronisierte Credential Manager: Der iCloud-Schlüsselbund in Safari und der Google Passwortmanager in Chrome liefern typischerweise ["internal", "hybrid"], um sowohl lokale als auch geräteübergreifende Authentifizierungsabläufe zu unterstützen.

Diese Informationen fließen in Web-Kontexten zuverlässig, obwohl die spezifischen Transports davon abhängen, welchen Authenticator der Browser für die Speicherung der Anmeldeinformationen auswählt.

Dokumentation: W3C WebAuthn Specification

Die Credential Manager API von Android verhält sich ähnlich wie Webbrowser. Beim Erstellen von Passkeys in nativen Android-Apps liefert der Credential Manager Transportinformationen, die das Web-Verhalten widerspiegeln – Plattform-Authenticators melden ihre Fähigkeiten korrekt, und das System behandelt Transportdaten konsistent. Android-Entwickler können sich auf diese Informationen ohne spezielle Behandlung verlassen.

Dokumentation: Android Credential Manager

iOS stellt eine komplexere Situation dar. Apples AuthenticationServices Framework behandelt Transports je nach Authenticator-Typ unterschiedlich:

Plattform-Authenticators (iCloud-Schlüsselbund, verifiziert durch Face ID oder Touch ID): Geben bei der Passkey-Erstellung oft leere Transport-Arrays zurück. Das bedeutet nicht, dass der Passkey keine Transportfähigkeiten hat – es bedeutet lediglich, dass iOS sie nicht explizit meldet. Gemäß dem WebAuthn-Standard bedeutet das Weglassen von Transports, dass jeder Transport akzeptabel ist, sodass die hybride Authentifizierung weiterhin funktioniert.

Sicherheitsschlüssel: Liefern Transportinformationen (z. B. ["usb"], ["nfc"]), wenn sie mit iOS-Geräten verwendet werden, und folgen dem erwarteten Muster.

Dokumentation: Apple AuthenticationServices

Entwickler stehen vor der Wahl: die Spezifikation strikt befolgen oder interne und hybride Transports für eine bessere Nutzererfahrung optimieren. Jeder Ansatz hat Vor- und Nachteile.

Dieser Ansatz richtet sich nach der WebAuthn-Spezifikation: Verwenden Sie die Transports genau so, wie sie vom Authenticator bei der Registrierung der Anmeldeinformationen bereitgestellt werden, und senden Sie sie bei der Authentifizierung unverändert zurück.

Implementierung: Wenn ein Passkey erstellt wird, speichern Sie das transports-Array aus der Authenticator-Antwort. Fügen Sie bei der Authentifizierung genau diese Transports in die allowCredentials-Liste ein:

{
    "allowCredentials": [
        {
            "id": "credential-id-base64",
            "type": "public-key",
            "transports": ["internal", "hybrid"]
        }
    ]
}

Vorteile:

• Spezifikationskonformität: Folgt den WebAuthn-Standards genau und gewährleistet die Kompatibilität mit zukünftigen Plattform-Updates.
• Zuverlässigkeit bei Sicherheitsschlüsseln: Funktioniert perfekt für Hardware-Sicherheitsschlüssel (YubiKeys usw.), die immer genaue Transportinformationen liefern.
• Verhindert ungültige Optionen: Vermeidet das Anbieten von Authentifizierungsmethoden, die wirklich nicht unterstützt werden – löst z. B. keine QR-Codes für Windows Hello-Anmeldeinformationen aus.

Nachteile:

• Verhalten bei leeren iOS-Arrays: Plattform-Authenticators auf iOS geben leere Transports zurück, was laut Spezifikation „jeder Transport“ bedeutet – dies kann alle Authentifizierungsoptionen anzeigen, einschließlich Sicherheitsschlüssel.
• Kann unerwünschte Optionen anzeigen: Könnte Sicherheitsschlüssel-Optionen (USB, NFC) in Verbraucheranwendungen anzeigen, wo sie nicht erwartet werden.
• Inkonsistente Nutzererfahrung: Verschiedene Plattformen bieten unterschiedliche Authentifizierungsoptionen für dasselbe Konto.

Am besten geeignet für: Anwendungen, die die Einhaltung von Standards priorisieren, und Unternehmensumgebungen mit verschiedenen Authenticator-Typen.

Dieser Ansatz priorisiert die Nutzererfahrung, indem interne und hybride Transports basierend auf spezifischen Optimierungszielen selektiv modifiziert werden. Anstelle einer pauschalen Regel betrachten wir diese gängigen Optimierungsszenarien:

Problem: iOS-Plattform-Authenticators geben leere Transport-Arrays zurück. Wenn diese leer gelassen oder von Backends gefüllt werden, sehen Nutzer möglicherweise Aufforderungen für Sicherheitsschlüssel (USB, NFC) neben den Plattformoptionen, was in Verbraucheranwendungen zu Verwirrung führen kann.

Lösung: Setzen Sie die Transports für iOS-Plattform-Authenticators explizit auf ["hybrid", "internal"]. Dies stellt sicher, dass nur die Plattform-Authentifizierung und geräteübergreifende Abläufe angeboten werden und Sicherheitsschlüssel-Optionen ausgeblendet werden.

// Beim Speichern von iOS-Plattform-Authenticator-Anmeldeinformationen
if (platform === "iOS" && authenticatorAttachment === "platform") {
    transports = ["hybrid", "internal"];
}

Ergebnis: Eine saubere Authentifizierungs-UI ohne Aufforderungen für Sicherheitsschlüssel bei auf iOS erstellten Passkeys.

Problem: Bei der Authentifizierung auf Mobilgeräten führt die Anzeige von QR-Codes für die geräteübergreifende Authentifizierung zu einer schlechten UX – die Nutzer befinden sich bereits auf einem mobilen Gerät, auf dem ihre Passkeys verfügbar sind.

Lösung: Entfernen Sie den hybrid-Transport, wenn sich der Nutzer von einem mobilen Gerät aus authentifiziert, und lassen Sie nur ["internal"] übrig.

// Beim Erstellen von allowCredentials für die Authentifizierung
const transports = isMobileDevice
    ? credentials.transports.filter((t) => t !== "hybrid")
    : credentials.transports;

Ergebnis: Mobile Nutzer sehen nur direkte Authentifizierungsoptionen ohne unnötige QR-Code-Aufforderungen.

⚠️ Vorsicht: Die Manipulation von Transports führt nicht immer zu konsistenten Ergebnissen auf allen Plattformen. Umfangreiche Tests zeigen, dass Browser- und Betriebssystemkombinationen Transports unterschiedlich handhaben:

• Einige Plattformen zeigen QR-Codes an, auch wenn hybrid aus den Transports ausgeschlossen ist.
• Andere verbergen QR-Codes, auch wenn hybrid enthalten ist.
• Das Verhalten variiert erheblich zwischen Chrome, Edge, Safari und Firefox auf Windows, macOS und iOS.

Risiko von Sackgassen: Eine zu restriktive Filterung von Transports kann zu Authentifizierungs-Sackgassen führen, in denen sich Nutzer überhaupt nicht anmelden können. Das Entfernen von hybrid könnte beispielsweise legitime geräteübergreifende Authentifizierungsszenarien verhindern, in denen sich ein Nutzer von einem geliehenen Gerät aus authentifizieren muss. Stellen Sie immer alternative Authentifizierungsmethoden bereit und testen Sie gründlich auf allen Zielplattformen, bevor Sie Transportoptimierungen einsetzen.

Dies sind Optimierungshinweise: WebAuthn bietet neben der Transportmanipulation auch andere Mechanismen zur Optimierung der Authentifizierungs-UX – wie z. B. Hints.

Das Transportverhalten ist unvorhersehbar: Die geräteübergreifende Authentifizierung (CDA) über den hybrid-Transport zeigt ein inkonsistentes Verhalten bei verschiedenen Browser- und Betriebssystemkombinationen. Tests aus der Praxis zeigen, dass Transportwerte kein spezifisches UI-Verhalten garantieren – Plattformen interpretieren und handhaben Transports unterschiedlich, was zu unerwarteten Ergebnissen führt.

Plattformspezifische Komplexität: Wenn Sie Transports explizit steuern, müssen Sie die Unterschiede zwischen den Plattformen berücksichtigen:

• iOS: Sendet leere Arrays für Plattform-Authenticators; erfordert ein Auffüllen.
• Windows Hello: Muss ["internal"] bleiben; das Hinzufügen von hybrid löst unerwünschte QR-Codes aus.
• Web & Android: Liefern im Allgemeinen genaue Transportinformationen.
• CDA-Variationen: QR-Code-Aufforderungen können unabhängig vom Vorhandensein von hybrid im Transports-Array erscheinen oder verschwinden.

End-to-End-Verständnis erforderlich: Die explizite Steuerung von Transports bedeutet, die Verantwortung für den gesamten Ablauf zu übernehmen. Sie müssen verstehen, wie sich jede Transportkombination auf all Ihren Zielplattformen verhält und gründlich testen. Die Manipulation von Transports kann zu Authentifizierungs-Sackgassen führen, in denen für Nutzer kein gültiger Authentifizierungspfad existiert.

Vorteile:

• Maßgeschneiderte UX: Genaue Kontrolle darüber, welche Authentifizierungsoptionen Nutzer in bestimmten Kontexten sehen.
• Löst das Problem der leeren iOS-Arrays: Definiert explizit Transports, wo iOS keine bereitstellt.
• Kontextbezogene Optimierung: Passt die Authentifizierungs-UI an den Gerätetyp an.

Nachteile:

• Unvorhersehbares Verhalten: Die Manipulation von Transports garantiert kein konsistentes UI-Verhalten – umfangreiche Tests zeigen, dass Plattformen Transports unterschiedlich interpretieren und Optionen manchmal unabhängig von den Transportwerten anzeigen oder ausblenden.
• Risiko von Authentifizierungs-Sackgassen: Eine zu restriktive Filterung von Transports kann Nutzer vollständig an der Authentifizierung hindern, insbesondere in geräteübergreifenden Szenarien.
• Abweichung von der Spezifikation: Entfernt sich von den Empfehlungen der Spezifikation, was möglicherweise zu Problemen bei zukünftigen Plattformänderungen führt.
• Wartungsaufwand: Erfordert kontinuierliche plattformspezifische Logik und Updates, während sich die Plattformen weiterentwickeln.
• Komplexität: Muss leere iOS-Arrays, Einschränkungen von Windows Hello und andere plattformspezifische Eigenheiten manuell behandeln.
• Testaufwand: Jede Optimierungsregel muss für alle Plattformkombinationen verifiziert werden.

Am besten geeignet für: Verbraucheranwendungen mit spezifischen UX-Anforderungen, Teams mit Ressourcen zur Pflege plattformspezifischer Logik, Szenarien, die optimierte Authentifizierungsabläufe über strikte Spezifikationskonformität stellen.

Der Umgang mit WebAuthn-Transports existiert nicht isoliert – er ist ein Teil Ihrer gesamten Passkey-Implementierungsstrategie. In Produktionsumgebungen kristallisieren sich zwei gängige Ansätze heraus, jeder mit unterschiedlichen Auswirkungen auf die Nutzung von internen und hybriden Transports.

Dieser Ansatz priorisiert Flexibilität und die Einhaltung von Standards und ermöglicht es den Nutzern, sich mit jedem kompatiblen Authenticator zu authentifizieren.

Implementierungsmerkmale:

• Authentifizierungs-UI: Der Passkey-Button erscheint neben den bestehenden Anmeldeoptionen (Benutzername/Passwort).
• allowCredentials: Wird auf ein leeres Array [] gesetzt, sodass jede Anmeldeinformation übereinstimmen kann.
• Authenticator-Typen: Sicherheitsschlüssel, geräteübergreifende Authentifizierung (QR-Codes) und Plattform-Authenticators werden alle unterstützt.
• Anforderungen an native Apps: Müssen alle Authentifizierungsmethoden unterstützen, einschließlich Sicherheitsschlüssel.
• preferImmediatelyAvailableCredentials: Kann nicht verwendet werden, da es per Definition Sicherheitsschlüssel und QR-Code-Logins ausschließt.
• Umgang mit Transports: Muss alle Transporttypen berücksichtigen, einschließlich der Transports für Sicherheitsschlüssel (usb, nfc, ble).

Auswirkungen auf Transports:

Mit einem leeren allowCredentials werden Transports während der Authentifizierung weniger kritisch – die Plattform zeigt alle verfügbaren Optionen an. Dies bedeutet jedoch, dass Nutzer möglicherweise gleichzeitig Aufforderungen für Sicherheitsschlüssel, QR-Codes und Plattformoptionen sehen, was in Verbraucheranwendungen zu einer Entscheidungslähmung führen kann.

Am besten geeignet für: Unternehmensumgebungen, Anwendungen mit vielfältigen Nutzerbasen, die Unterstützung für Sicherheitsschlüssel benötigen, und Szenarien, die maximale Authentifizierungsflexibilität priorisieren.

Dieser Ansatz optimiert die UX für Verbraucher, indem die Passkey-Erstellung auf Plattform-Authenticators beschränkt und Identifier-First-Flows verwendet werden.

Implementierungsmerkmale:

• Passkey-Erstellung: Nur Plattform-Authenticators sind über authenticatorAttachment: "platform" erlaubt.
• Authentifizierungsablauf: Identifier-First – Nutzer geben ihre E-Mail/ihren Benutzernamen vor der Authentifizierung ein.
• allowCredentials: Wird mit den spezifischen Anmeldeinformationen des Nutzers gefüllt (nicht leer), sobald der Identifier bekannt ist.
• Authenticator-Typen: Plattform-Authenticators und geräteübergreifende Authentifizierung; Sicherheitsschlüssel sind in der Regel ausgeschlossen.
• Optimierung nativer Apps: Kann preferImmediatelyAvailableCredentials verwenden, was per Definition Sicherheitsschlüssel und geräteübergreifende Authentifizierung ausschließt.
• Geräteübergreifende Authentifizierung: Im Web verfügbar; nicht verfügbar bei Verwendung von preferImmediatelyAvailableCredentials in nativen Apps, aber dieses Szenario ist selten (Nutzer haben ihre Passkeys normalerweise auf dem Gerät, das sie verwenden).
• Umgang mit Transports: Konzentriert sich nur auf internal- und hybrid-Transports.

Auswirkungen auf Transports:

Da allowCredentials spezifische Anmeldeinformationen mit ihren Transports enthält, wird der Umgang mit Transports entscheidend.

Am besten geeignet für: Verbraucheranwendungen, native mobile Apps, Szenarien, die eine optimierte UX über die Flexibilität des Authenticators stellen, und Plattformen, auf denen Identifier-First-Flows bereits existieren.

Für Plattformen, die bereits die Existenz von Konten preisgeben oder Identifier-First-Flows verwenden (Nutzer gibt E-Mail ein, bevor Anmeldeoptionen angezeigt werden), passt der auf Verbraucher zugeschnittene Ansatz natürlich. Sobald der Nutzer seinen Identifier angegeben hat:

1. Das Backend fragt nach vorhandenen Passkeys.
2. Gibt allowCredentials mit spezifischen Anmeldeinformationen und deren Transports zurück.
3. Die Plattform kann die Authentifizierungs-UI basierend auf den Transports optimieren.
4. Kein zusätzliches Risiko der Kontoauflistung (Identifier wurde bereits angegeben).

In diesen Szenarien können Transports eher zu einem Optimierungswerkzeug als zu einem Sicherheitsproblem werden. Sie können Authentifizierungsoptionen basierend auf dem Gerätekontext (mobil vs. Desktop) und den Fähigkeiten der Anmeldeinformationen anpassen.

Empfehlung: Für Plattformen, die bereits Identifier-First-Flows verwenden oder bei denen die Kontoauflistung kein Problem darstellt, bietet der auf Verbraucher zugeschnittene Ansatz mit explizitem Transport-Handling eine überlegene UX, insbesondere in nativen mobilen Anwendungen, in denen preferImmediatelyAvailableCredentials eine nahtlose biometrische Authentifizierung ermöglicht.

Unabhängig davon, für welchen Ansatz Sie sich beim Umgang mit internen und hybriden Transports entscheiden, befolgen Sie diese Praktiken, um Probleme zu minimieren:

Transports bei der Registrierung speichern: Speichern Sie immer das transports-Array aus der Authenticator-Antwort zusammen mit der Credential ID und dem öffentlichen Schlüssel. Diese Daten sind für Authentifizierungsabläufe unerlässlich.

Leere Arrays korrekt behandeln: Wenn Sie ein leeres Transport-Array von iOS-Plattform-Authenticators erhalten:

• Spezifikationskonform: Leer lassen oder die transports-Eigenschaft weglassen – bedeutet, „jeder Transport“ ist akzeptabel.
• Optimierungsansatz: Mit ["internal", "hybrid"] füllen, um zu steuern, welche Authentifizierungsoptionen angezeigt werden.

Auf allen Zielplattformen testen: Erstellen Sie eine Testmatrix, die alle Kombinationen abdeckt:

• Registrierung: Web, iOS Nativ, Android Nativ
• Authentifizierung: Web, iOS Nativ, Android Nativ
• Überprüfen Sie, ob QR-Codes wie erwartet erscheinen und ausgeblendet werden, wenn dies unangebracht ist.

Leeres Array vs. fehlende Eigenschaft verstehen: Sowohl ein leeres transports-Array [] als auch eine fehlende transports-Eigenschaft werden gemäß der Spezifikation typischerweise als „jeder Transport ist akzeptabel“ behandelt. Die Implementierungsdetails variieren jedoch zwischen den Plattformen.

Plattformänderungen überwachen: WebAuthn-Implementierungen entwickeln sich weiter. Apple, Google und Microsoft aktualisieren regelmäßig das Verhalten ihrer Authenticators. Bleiben Sie über Änderungen informiert, die den Umgang mit Transports beeinflussen könnten.

WebAuthn-Transports – insbesondere interne und hybride Transports – sind technische Details mit erheblichen praktischen Auswirkungen auf die geräteübergreifende Authentifizierung. Ihre Strategie für den Umgang mit Transports sollte mit Ihrem allgemeinen Passkey-Implementierungsansatz und Ihren Zielplattformen übereinstimmen.

Transportentscheidungen sind Teil einer größeren Strategie: Wie Sie mit Transports umgehen, hängt davon ab, ob Sie auf maximale Flexibilität (leere allowCredentials) oder auf eine verbraucherorientierte UX (Identifier-First mit spezifischen Anmeldeinformationen) abzielen. Letzteres macht Transports für die Optimierung entscheidend.

Plattformunterschiede erfordern eine Handhabung: Web und Android liefern zuverlässige Transportinformationen, während iOS-Plattform-Authenticators leere Arrays zurückgeben. Windows Hello sendet nur ["internal"]. Das Verständnis dieser Unterschiede ist für Produktionsumgebungen unerlässlich.

Zwei gültige Transportansätze: Der spezifikationskonforme Ansatz (Vertrauen auf Authenticator-Transports) funktioniert gut für Unternehmens- und maximale Flexibilitätsszenarien. Die explizite Kontrolle (Optimierung der Transports) eignet sich für Verbraucheranwendungen mit Identifier-First-Flows und native mobile Apps.

Identifier-First ermöglicht die Transportoptimierung: Wenn Nutzer zuerst ihren Identifier angeben, wird der Umgang mit Transports zu einem leistungsstarken UX-Werkzeug. Sie können unerwünschte QR-Codes auf Mobilgeräten verhindern, Optionen für Sicherheitsschlüssel ausblenden und die Authentifizierung optimieren – ohne zusätzliche Bedenken hinsichtlich der Kontoauflistung.

Für Unternehmen / Maximale Flexibilität:

• Verwenden Sie leere allowCredentials, um alle Authenticator-Typen zu unterstützen.
• Vertrauen Sie den vom Authenticator bereitgestellten Transports.
• Akzeptieren Sie, dass Nutzer mehr Authentifizierungsoptionen sehen.
• Einfachere Implementierung, breitere Kompatibilität.

Für Verbraucheranwendungen / Native Apps:

• Implementieren Sie einen Identifier-First-Authentifizierungsablauf.
• Beschränken Sie sich auf Plattform-Authenticators (authenticatorAttachment: "platform").
• Verwenden Sie allowCredentials mit spezifischen Anmeldeinformationen und optimierten Transports.
• Aktivieren Sie preferImmediatelyAvailableCredentials in nativen Apps.
• Füllen Sie leere iOS-Arrays mit ["hybrid", "internal"].
• Filtern Sie hybrid auf mobilen Geräten, um QR-Codes zu verhindern.
• Überlegene UX mit optimierten Authentifizierungsoptionen.

Für Plattformen, die bereits Identifier-First-Flows verwenden:

• Die Kontoauflistung ist bereits kein Thema mehr.
• Der auf Verbraucher zugeschnittene Ansatz passt natürlich zur bestehenden UX.
• Die Transportoptimierung bietet sofortige UX-Vorteile.
• Empfohlener Ansatz für die meisten Verbraucheranwendungen.

Beginnen Sie spezifikationskonform, und optimieren Sie dann basierend auf Ihrer Strategie:

1. Speichern Sie die Transports genau so, wie sie bei der Registrierung empfangen wurden.
2. Entscheiden Sie sich für Ihre Gesamtstrategie (maximale Flexibilität vs. verbraucherorientiert).
3. Wenn verbraucherorientiert: Implementieren Sie einen Identifier-First-Flow und optimieren Sie die Transports.
4. Behandeln Sie leere iOS-Arrays entsprechend Ihrer gewählten Strategie.
5. Testen Sie gründlich auf Web-, iOS-nativen und Android-nativen Plattformen.

Die WebAuthn-Landschaft entwickelt sich ständig weiter. Plattformanbieter aktualisieren regelmäßig ihre Implementierungen, und Spezifikationen wie WebAuthn Level 3 führen neue Funktionen ein. Der Aufbau flexibler Systeme, die den Umgang mit Transports mit Ihrer umfassenderen Authentifizierungsstrategie in Einklang bringen, stellt sicher, dass Ihre Passkey-Implementierung robust bleibt und hervorragende Nutzererfahrungen bietet, während das Ökosystem reift.