WebAuthn Transports: Internal und Hybrid Transport

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

Whitepaper erhalten

Hinweis: Gemäß der WebAuthn-Spezifikation bedeutet eine leere Transport-Sequenz, dass Transportinformationen nicht verfügbar sind oder aus Datenschutzgründen zurückgehalten werden. Wird von Browsern oft so behandelt, als ob alle Transports möglich wären.

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

• Wie sollten Sie WebAuthn Transports, insbesondere internal und hybrid Transports, handhaben, um optimale geräteübergreifende Authentifizierungserlebnisse zu gewährleisten?

Die Antwort liegt im Verständnis von WebAuthn Transports – einem technischen Detail, das bestimmt, wie Authentifikatoren mit Relying Parties kommunizieren. Während Transports in der Theorie einfach erscheinen, variiert ihre Implementierung erheblich zwischen Webbrowsern, nativen iOS- und nativen Android-Anwendungen, insbesondere für das Handling von internal und hybrid Transports.

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

Dieser Artikel behandelt:

1. WebAuthn Transports: internal, hybrid und Plattform-Authentifikatoren in Web, iOS und Android
2. Zwei Ansätze: Spezifikationskonformes vs. optimiertes Handling von internal und hybrid Transports
3. Best Practices und Empfehlungen für die Implementierung der geräteübergreifenden Authentifizierung

WebAuthn Transports definieren die Kommunikationsmethoden zwischen Authentifikatoren 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-Sicherheits-Token.

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

ble: Erleichtert die Authentifizierung über Bluetooth Low Energy, was die drahtlose Kommunikation mit externen Authentifikatoren ermöglicht.

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

hybrid: Ermöglicht die geräteübergreifende Authentifizierung, typischerweise dort, wo ein Benutzer einen QR-Code scannt, um sich geräteübergreifend zu authentifizieren – z. B. mithilfe eines Telefons zur Authentifizierung 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 Authentifikator ist in das Gerät selbst eingebettet – wie iCloud-Schlüsselbund (verifiziert über Face ID oder Touch ID) auf iPhones, Windows Hello auf PCs oder Google Passwortmanager auf Android-Geräten. Dies sind Plattform-Authentifikatoren.

Wenn ein Passkey erstellt wird, signalisiert der Authentifikator, welche Transports er unterstützt. Diese Informationen werden an die Relying Party (Ihr Backend) gesendet, die sie neben den Anmeldeinformationen beibehalten sollte. Während der Authentifizierung sendet die Relying Party diese Transports in der Liste allowCredentials an den Client zurück, wodurch der Browser oder die Plattform ermitteln kann, welche Authentifizierungsmethoden dem Benutzer angeboten werden sollen.

Das Transport-Handling unterscheidet sich erheblich zwischen den Plattformen, was die Kompatibilitätsprobleme verursacht, mit denen Entwickler konfrontiert sind.

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

Plattform-Authentifikatoren: Windows Hello liefert nur ["internal"], was seine gerätegebundene Natur widerspiegelt. Wenn Chrome jedoch den Google Passwortmanager als Authentifikator verwendet, liefert es ["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: iCloud-Schlüsselbund in Safari und 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 zuverlässig in Webkontexten, obwohl die spezifischen Transports davon abhängen, welchen Authentifikator der Browser für die Speicherung der Anmeldeinformationen auswählt.

Dokumentation: W3C WebAuthn Spezifikation

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 Webverhalten widerspiegeln – Plattform-Authentifikatoren melden ihre Fähigkeiten genau, und das System behandelt Transportdaten konsistent. Android-Entwickler können sich ohne besondere Behandlung auf diese Informationen verlassen.

Dokumentation: Android Credential Manager

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

Plattform-Authentifikatoren (iCloud-Schlüsselbund, verifiziert über Face ID oder Touch ID): Geben bei der Passkey-Erstellung oft leere Transport-Arrays zurück. Dies weist darauf hin, dass Transportinformationen nicht verfügbar sind oder aus Datenschutzgründen zurückgehalten werden – gemäß der WebAuthn-Spezifikation können User Agents leere Sequenzen zurückgeben, wenn Transportinformationen unbekannt sind oder um die Privatsphäre zu wahren. Relying Parties sollten Transports eher als Hinweise denn als Garantien behandeln.

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

Dokumentation: Apple AuthenticationServices

Reale Produktionsdaten aus Web- und nativen Anwendungen zeigen die folgenden Transportmuster, geordnet nach Häufigkeit. Beachten Sie, dass diese Verteilungen durch Implementierungsdetails und Client-Demografien (mobile vs. Desktop-Nutzung, Verfügbarkeit nativer Apps) beeinflusst werden, aber sie bieten wertvolle Einblicke in die typische Transportnutzung:

Wichtigste Erkenntnisse:

Plattform-Authentifikatoren dominieren: Die überwiegende Mehrheit der Passkeys verwendet den Transport internal, oft kombiniert mit hybrid für die Unterstützung der geräteübergreifenden Authentifizierung. Dies spiegelt den Verbraucherfokus auf Plattform-Authentifikatoren (iCloud-Schlüsselbund, Google Passwortmanager) wider.

Leere Arrays sind häufig: Native iOS-Anwendungen geben für Plattform-Authentifikatoren häufig leere Transport-Arrays zurück, was einen erheblichen Teil der produktiven Anmeldeinformationen ausmacht. Wie in Abschnitt 2.2.3 erläutert, weisen diese eher auf nicht verfügbare Transportinformationen als auf eine umfassende Transportunterstützung hin.

Sicherheitsschlüssel sind selten: Hardware-Sicherheitsschlüssel (usb, nfc) machen einen winzigen Bruchteil der Produktions-Passkeys aus, was auf ihre primäre Verwendung in Unternehmens- oder Hochsicherheitsszenarien anstelle von Consumer-Anwendungen hindeutet.

Reihenfolgevariationen existieren: Die Reihenfolge der Transports in Arrays (["internal", "hybrid"] vs. ["hybrid", "internal"]) variiert je nach Plattform- und Authentifikatorimplementierung, hat aber keinen funktionalen Unterschied – beide weisen auf die Unterstützung derselben Transportmethoden hin.

Veraltete Terminologie: Die Transport-Kennung cable taucht gelegentlich in älteren Implementierungen auf und ist synonym mit hybrid (caBLE = cloud-assisted Bluetooth Low Energy, der ursprüngliche Name für den Hybrid-Transport).

Diese Verteilung unterstreicht, wie wichtig es ist, internal und hybrid Transports korrekt zu handhaben, da sie den überwältigenden Großteil der realen Passkey-Implementierungen ausmachen.

Die Transportverfügbarkeit zeigt, was Authentifikatoren melden, nicht, ob der resultierende Ablauf abgeschlossen wird. Die Analyse des Corbado Passkey Benchmark 2026 zum Abschluss der geräteübergreifenden Authentifizierung misst für das 1. Quartal 2026 einen Abschluss beim hybrid-Transport von 60–78 % im Windows-Web und 66–86 % im macOS-Web insgesamt, was sich aufteilt in 79–98 % (Win) / 83–98 % (macOS) für Same-Device-Nudges gegenüber 52–67 % (Win) / 59–76 % (macOS) für Identifier-First-Abläufe. Behandeln Sie hybrid als den Transport mit den höchsten Kosten in der Routing-Logik und bevorzugen Sie Abläufe, bei denen der Benutzer auf dem Gerät bleibt, das die Anmeldeinformationen enthält.

Derselbe Authentifikator meldet oft unterschiedliche Transportmuster basierend auf Plattform, Version und Implementierungskontext. Diese Variation ist normal und zu erwarten:

iCloud-Schlüsselbund zeigt drei Muster:

• ["internal", "hybrid"] - Am häufigsten, typischerweise aus Webbrowsern
• [] (leeres Array) - Sehr häufig, aus nativen iOS-Apps
• ["hybrid", "internal"] - Weniger häufig, Variation in der Reihenfolge
• ["internal"] oder ["hybrid"] allein - Seltene Randfälle

Google Passwortmanager zeigt die größte Variation:

• ["hybrid", "internal"] - Häufigstes Muster
• ["internal", "hybrid"] - Häufige alternative Reihenfolge
• ["internal", "cable"] - Legacy-Implementierungen (cable = alter Begriff für hybrid)
• [] (leeres Array) - Aus bestimmten nativen Kontexten
• Einzelne Transports selten

Windows Hello ist am konsistentesten:

• ["internal"] - Dominantes Muster (durch das Design gerätegebunden)

Passwortmanager wie 1Password, Bitwarden, Dashlane und LastPass zeigen alle ähnliche Variationsmuster:

• Sowohl ["internal", "hybrid"]- als auch ["hybrid", "internal"]-Reihenfolgen
• Leere Arrays [] aus nativen App-Kontexten
• Gelegentlich nur ["internal"]

Samsung Pass (Android-Ökosystem) verwendet primär:

• ["hybrid", "internal"] und ["internal", "hybrid"] - Beide Reihenfolgen häufig

Plattformunterschiede: Derselbe Authentifikator verhält sich im Web im Vergleich zu nativ, iOS im Vergleich zu Android oder Windows im Vergleich zu macOS unterschiedlich.

Versionsentwicklung: Die Transportberichterstattung hat sich im Laufe der Zeit weiterentwickelt. Ältere Versionen verwenden möglicherweise cable anstelle von hybrid oder melden andere Kombinationen.

Implementierungsentscheidungen: Einige Authentifikatoren priorisieren internal zuerst, andere hybrid. Die Reihenfolge hat keine funktionalen Auswirkungen, variiert jedoch je nach Implementierung.

Kontextsensibilität: Native Apps, insbesondere unter iOS, erhalten oft leere Arrays, selbst von Authentifikatoren, die in Webkontexten vollständige Transports melden.

Wichtigste Erkenntnis: Gehen Sie nicht davon aus, dass Transport-Arrays für einen bestimmten Authentifikator konsistent sind. Entwerfen Sie Ihre Implementierung so, dass alle Variationen elegant gehandhabt werden, wobei der Fokus auf dem Vorhandensein bestimmter Transports liegt, anstatt auf dem genauen Array-Abgleich.

Entwickler haben die Wahl: sich strikt an die Spezifikation zu halten oder internal und hybrid Transports für die Benutzererfahrung zu optimieren. Jeder Ansatz hat Vor- und Nachteile.

Dieser Ansatz stimmt mit der WebAuthn-Spezifikation überein: Verwenden Sie Transports genau so, wie sie vom Authentifikator während der Registrierung der Anmeldeinformationen bereitgestellt werden, und senden Sie sie während der Authentifizierung unverändert zurück.

Implementierung: Wenn ein Passkey erstellt wird, behalten Sie das transports-Array aus der Antwort des Authentifikators bei. Fügen Sie diese genauen Transports während der Authentifizierung in die Liste allowCredentials ein:

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

Vorteile:

• Spezifikationskonformität: Befolgt die WebAuthn-Standards präzise und stellt die Kompatibilität mit zukünftigen Plattform-Updates sicher
• 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 beispielsweise keine QR-Codes für Windows Hello-Anmeldeinformationen aus

Nachteile:

• Verhalten bei leeren Arrays unter iOS: Plattform-Authentifikatoren unter iOS geben leere Transports zurück, was auf nicht verfügbare Transportinformationen hinweist – Plattformen können dies unterschiedlich interpretieren, wenn sie bestimmen, welche Authentifizierungsoptionen angezeigt werden sollen
• Kann unerwünschte Optionen anzeigen: Könnte Optionen für Sicherheitsschlüssel (USB, NFC) in Consumer-Anwendungen präsentieren, in denen sie nicht erwartet werden
• Inkonsistente Benutzererfahrung: Verschiedene Plattformen bieten unterschiedliche Authentifizierungsoptionen für dasselbe Konto an

Am besten für: Anwendungen, die die Einhaltung von Standards priorisieren, Unternehmensumgebungen mit diversen Authentifikatortypen.

Dieser Ansatz priorisiert die Benutzererfahrung, indem er internal und hybrid Transports basierend auf bestimmten Optimierungszielen selektiv modifiziert. Berücksichtigen Sie anstelle einer pauschalen Regel diese häufigen Optimierungsszenarien:

Problem: iOS-Plattform-Authentifikatoren geben leere Transport-Arrays zurück. Wenn sie leer gelassen oder von Backends gefüllt werden, sehen Benutzer möglicherweise Eingabeaufforderungen für Sicherheitsschlüssel (USB, NFC) neben den Plattformoptionen, was in Consumer-Anwendungen Verwirrung stiftet.

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

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

Ergebnis: Saubere Authentifizierungs-Benutzeroberfläche ohne Eingabeaufforderungen für Sicherheitsschlüssel für von iOS erstellte 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 – Benutzer befinden sich bereits auf einem Mobilgerät, auf dem ihre Passkeys verfügbar sind.

Lösung: Entfernen Sie den Transport hybrid, wenn sich der Benutzer über ein Mobilgerät authentifiziert, und belassen Sie nur ["internal"].

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

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

⚠️ Achtung: Die Transportmanipulation führt nicht immer zu konsistenten Ergebnissen auf allen Plattformen. Umfangreiche Tests zeigen, dass Browser- und OS-Kombinationen Transports unterschiedlich handhaben:

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

Risiko von Sackgassen: Eine zu restriktive Transportfilterung kann Authentifizierungs-Sackgassen erzeugen, in denen sich Benutzer überhaupt nicht anmelden können. Beispielsweise könnte das Entfernen von hybrid legitime geräteübergreifende Authentifizierungsszenarien verhindern, in denen sich ein Benutzer von einem geliehenen Gerät authentifizieren muss. Stellen Sie immer Fallback-Authentifizierungsmethoden bereit und testen Sie diese gründlich auf Ihren Zielplattformen, bevor Sie Transportoptimierungen bereitstellen.

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

Transportverhalten ist unvorhersehbar: Die geräteübergreifende Authentifizierung (CDA) über den Transport hybrid weist über Browser- und OS-Kombinationen hinweg ein inkonsistentes Verhalten auf. Reale Tests zeigen, dass Transportwerte kein spezifisches UI-Verhalten garantieren – Plattformen interpretieren und handhaben Transports unterschiedlich, was zu unerwarteten Ergebnissen führt.

Plattformspezifische Komplexität: Bei der expliziten Steuerung von Transports müssen Sie Plattformunterschiede berücksichtigen:

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

End-to-End-Verständnis erforderlich: Die explizite Steuerung von Transports bedeutet, 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 Transportmanipulation kann Authentifizierungs-Sackgassen erzeugen, in denen kein gültiger Authentifizierungspfad für Benutzer existiert.

Vorteile:

• Maßgeschneidererte UX: Steuern Sie genau, welche Authentifizierungsoptionen Benutzern in bestimmten Kontexten angezeigt werden
• Löst das Problem leerer Arrays unter iOS: Definiert Transports explizit, wo iOS keine bereitstellt
• Kontextsensitive Optimierung: Passen Sie die Authentifizierungs-Benutzeroberfläche basierend auf dem Gerätetyp an

Nachteile:

• Unvorhersehbares Verhalten: Transportmanipulation garantiert kein konsistentes UI-Verhalten – umfangreiche Tests zeigen, dass Plattformen Transports unterschiedlich interpretieren und Optionen manchmal unabhängig von Transportwerten anzeigen oder ausblenden
• Risiko von Authentifizierungs-Sackgassen: Eine zu restriktive Transportfilterung kann Benutzer vollständig an der Authentifizierung hindern, insbesondere in geräteübergreifenden Szenarien
• Weicht von der Spezifikation ab: Entfernt sich von den Empfehlungen der Spezifikation und kann möglicherweise Probleme bei zukünftigen Plattformänderungen verursachen
• Wartungsaufwand: Erfordert fortlaufende plattformspezifische Logik und Updates im Zuge der Weiterentwicklung von Plattformen
• Komplexität: Muss leere Arrays unter iOS, Windows Hello-Einschränkungen und andere plattformspezifische Eigenheiten manuell behandeln
• Testaufwand: Jede Optimierungsregel muss über alle Plattformkombinationen hinweg verifiziert werden

Am besten für: Consumer-Anwendungen mit spezifischen UX-Anforderungen, Teams mit Ressourcen zur Pflege plattformspezifischer Logik, Szenarien, in denen optimierte Authentifizierungsabläufe einer strikten Spezifikationskonformität vorgezogen werden.

Das WebAuthn-Transport-Handling existiert nicht isoliert – es ist ein Teil Ihrer gesamten Passkey-Implementierungsstrategie. In Produktionsumgebungen kristallisieren sich zwei gängige Ansätze heraus, die jeweils unterschiedliche Auswirkungen auf die Nutzung von internal und hybrid Transports haben.

Dieser Ansatz priorisiert Flexibilität und Standardkonformität und ermöglicht es Benutzern, sich mit jedem kompatiblen Authentifikator zu authentifizieren.

Implementierungsmerkmale:

• Authentifizierungs-UI: Passkey-Button erscheint neben bestehenden Login-Optionen (Benutzername/Passwort)
• allowCredentials: Wird auf ein leeres Array [] gesetzt, wodurch jede Anmeldeinformation übereinstimmen kann
• Authentifikatortypen: Sicherheitsschlüssel, geräteübergreifende Authentifizierung (QR-Codes), Plattform-Authentifikatoren werden alle unterstützt
• Anforderungen an native Apps: Müssen alle Authentifizierungsmethoden einschließlich Sicherheitsschlüsseln unterstützen
• preferImmediatelyAvailableCredentials: Kann nicht verwendet werden, da Sicherheitsschlüssel und QR-Code-Logins per Definition ausgeschlossen sind
• Transport-Handling: Muss alle Transporttypen aufnehmen, einschließlich Sicherheitsschlüssel-Transports (usb, nfc, ble)

Auswirkungen auf den Transport:

Mit leerem allowCredentials werden Transports während der Authentifizierung weniger kritisch – die Plattform zeigt alle verfügbaren Optionen an. Das bedeutet jedoch, dass Benutzern möglicherweise gleichzeitig Aufforderungen für Sicherheitsschlüssel, QR-Codes und Plattformoptionen angezeigt werden, was in Consumer-Anwendungen zu einer Entscheidungsüberlastung führen kann.

Am besten für: Unternehmensumgebungen, Anwendungen mit diversen Benutzerbasen, die Unterstützung für Sicherheitsschlüssel benötigen, Szenarien, in denen maximale Authentifizierungsflexibilität im Vordergrund steht.

Dieser Ansatz optimiert die Consumer-UX, indem er die Erstellung von Passkeys auf Plattform-Authentifikatoren beschränkt und Identifier-First-Abläufe verwendet.

Implementierungsmerkmale:

• Passkey-Erstellung: Vom Benutzer initiierte Nudges (Post-Login-Aufforderungen, automatische Erstellungsabläufe) verwenden authenticatorAttachment: "platform", um sich auf sofort verfügbare Authentifikatoren zu konzentrieren
• Unterstützung für Sicherheitsschlüssel: Verfügbar über Web-Kontoeinstellungen ohne authenticatorAttachment-Einschränkung, sodass Power-User jeden Authentifikator einschließlich Sicherheitsschlüsseln auswählen können
• Authentifizierungsablauf: Identifier-First – Benutzer geben vor der Authentifizierung E-Mail/Benutzername ein
• allowCredentials: Wird mit den spezifischen Anmeldeinformationen des Benutzers gefüllt (nicht leer), sobald die Kennung bekannt ist
• Authentifikatortypen: Plattform-Authentifikatoren und geräteübergreifende Authentifizierung priorisiert; Sicherheitsschlüssel werden unterstützt, aber in den primären Abläufen nicht beworben
• Native App-Optimierung: Verwendet preferImmediatelyAvailableCredentials für eine stille, sofortige Authentifizierung ohne Aufforderungen für Sicherheitsschlüssel oder QR-Codes
• Geräteübergreifende Authentifizierung: Im Web verfügbar; in nativen Apps bei Verwendung von preferImmediatelyAvailableCredentials absichtlich ausgeschlossen (Benutzer authentifizieren sich typischerweise auf dem Gerät, auf dem sich ihre Passkeys befinden)
• Transport-Handling: Hauptaugenmerk auf internal und hybrid Transports

Auswirkungen auf den Transport:

Da allowCredentials spezifische Anmeldeinformationen mit ihren Transports enthält, wird das Transport-Handling für die Optimierung von Authentifizierungserlebnissen entscheidend.

Die Realität bei Sicherheitsschlüsseln: Sicherheitsschlüssel machen einen extrem kleinen Bruchteil der Passkey-Nutzung in groß angelegten Consumer-Implementierungen aus – in erster Linie Power-User oder Benutzer mit spezifischen Sicherheitsanforderungen. Der auf Verbraucher zugeschnittene Ansatz trägt dieser Realität Rechnung, indem er Sicherheitsschlüssel unterstützt, ohne primäre Abläufe um sie herum zu optimieren.

Zweistufige Erstellungsstrategie: Implementierungen können die Kompatibilität von Sicherheitsschlüsseln mit einer optimierten Consumer-UX durch duale Erstellungspfade ausbalancieren:

• Benutzer-Nudges und Aufforderungen: Post-Login-Aufforderungen und automatische Erstellungsabläufe verwenden authenticatorAttachment: "platform" und leiten Benutzer zu sofort verfügbaren Passkeys mit hohen Erfolgsraten
• Web-Kontoeinstellungen: Bietet die Erstellung ohne authenticatorAttachment, sodass Power-User Sicherheitsschlüssel, Passwortmanager von Drittanbietern oder jeden verfügbaren Authentifikator auswählen können

Dieses Muster tritt in großen Implementierungen auf: Sicherheitsschlüssel werden über Einstellungen unterstützt und sind funktionsfähig, aber benutzerorientierte Nudges optimieren den dominanten Anwendungsfall – Plattform-Authentifikatoren, die eine sofortige, stille Authentifizierung bieten.

Am besten für: Consumer-Anwendungen, native mobile Apps, Szenarien, in denen eine optimierte UX der Authentifikatorflexibilität vorgezogen wird, Plattformen, auf denen bereits Identifier-First-Abläufe vorhanden sind.

Für Plattformen, die bereits die Kontoexistenz preisgeben oder Identifier-First-Abläufe verwenden (Benutzer gibt die E-Mail ein, bevor Anmeldeoptionen angezeigt werden), passt der auf Verbraucher zugeschnittene Ansatz natürlich. Sobald der Benutzer seine Kennung eingegeben hat:

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

In diesen Szenarien können Transports eher zum Optimierungswerkzeug als zu einem Sicherheitsbedenken werden. Sie können Authentifizierungsoptionen basierend auf dem Gerätekontext (mobil vs. Desktop) und den Anmeldeinformationsfunktionen anpassen.

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

Unabhängig davon, welchen Ansatz Sie für die Handhabung von internal und hybrid Transports wählen, sollten Sie diese Praktiken befolgen, um Probleme zu minimieren:

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

Leere Arrays elegant handhaben: Wenn Sie ein leeres Transport-Array von iOS-Plattform-Authentifikatoren erhalten:

• Spezifikationskonform: Leer lassen oder Eigenschaft transports weglassen – zeigt an, dass Transportinformationen nicht verfügbar sind; Plattformen bestimmen die verfügbaren Optionen
• Optimierungsansatz: Füllen Sie mit ["internal", "hybrid"] auf, um zu steuern, welche Authentifizierungsoptionen angezeigt werden

Web- vs. Native-Transportstrategien: Differenzieren Sie das Transport-Handling basierend auf dem Kontext:

• Web-Authentifizierung: Schließen Sie alle Transports ein, um eine breitere Authentifikatorunterstützung zu ermöglichen, einschließlich Sicherheitsschlüsseln über USB/NFC
• Authentifizierung in nativen Apps: Verwenden Sie preferImmediatelyAvailableCredentials für stille Authentifizierung; Transports werden wie gespeichert gesendet
• Einstellungs-/Verwaltungsseiten: Unterstützen Sie alle Authentifikatortypen für Power-User

Authentifizierung mit Sicherheitsschlüssel handhaben: Wenn Benutzer registrierte Sicherheitsschlüssel haben:

• Web: Erkennen Sie Sicherheitsschlüssel-Transports in gespeicherten Anmeldeinformationen und stellen Sie sicher, dass Authentifizierungsabläufe diese aufnehmen können
• Native Apps: Erwägen Sie die Bereitstellung von Fallback-Authentifizierungsmethoden oder die Weiterleitung von Benutzern ans Web für die Authentifizierung mit Sicherheitsschlüsseln
• Hybrider Ansatz: Native Apps optimieren für Plattform-Authentifikatoren, während das Web die volle Authentifikatorflexibilität unterstützt

Über alle Zielplattformen hinweg 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 die stille Authentifizierung mit preferImmediatelyAvailableCredentials funktioniert
• Bestätigen Sie, dass Sicherheitsschlüssel in Einstellungsabläufen ohne authenticatorAttachment funktionieren
• Validieren Sie, dass QR-Codes nur in entsprechenden Kontexten erscheinen

Transport-Semantik verstehen: Erkennen Sie die Unterschiede zwischen leeren und fehlenden Transportwerten:

• Leeres Transports-Array []: Zeigt an, dass Transportinformationen nicht verfügbar sind oder aus Datenschutzgründen zurückgehalten werden. User Agents können leere Sequenzen bereitstellen, wenn sie Transportfähigkeiten nicht melden können oder wollen. Dies ist nicht gleichbedeutend mit „alle Transports unterstützt“ – behandeln Sie sie als Hinweise, wenn Informationen nicht verfügbar sind.
• Fehlende transports-Eigenschaft: Wenn transports in Credential-Deskriptoren fehlen, bestimmen User Agents die verfügbaren Authentifizierungsmethoden basierend auf anderen Faktoren. Der Kontext spielt eine Rolle: Bei Registrierungsantworten vs. Anforderungsoptionen für die Authentifizierung sind die Auswirkungen unterschiedlich.
• Transport-Hints: Gemäß Spezifikation sollten Transports als Hinweise behandelt werden, um User Agents bei der Optimierung der Authentifizierungs-UI zu helfen, und nicht als maßgebliche Garantien für Fähigkeiten.

Plattformänderungen überwachen: WebAuthn-Implementierungen entwickeln sich weiter. Apple, Google und Microsoft aktualisieren regelmäßig das Verhalten ihrer Authentifikatoren. Bleiben Sie über Änderungen informiert, die sich auf das Transport-Handling auswirken könnten.

WebAuthn Transports – insbesondere internal und hybrid Transports – sind technische Details mit erheblichen praktischen Auswirkungen auf die geräteübergreifende Authentifizierung. Ihre Strategie für das Transport-Handling sollte mit Ihrem breiteren Passkey-Implementierungsansatz und Ihren Zielplattformen übereinstimmen.

Transportentscheidungen leben innerhalb einer breiteren Strategie: Wie Sie Transports handhaben, hängt davon ab, ob Sie auf maximale Flexibilität (leeres allowCredentials) oder Consumer-UX (Identifier-First mit spezifischen Anmeldeinformationen) hinarbeiten. Letzteres macht Transports entscheidend für die Optimierung.

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

Zwei valide Transportansätze: Spezifikationskonform (Vertrauen auf Authentifikator-Transports) funktioniert gut für Unternehmen und Szenarien mit maximaler Flexibilität. Explizite Kontrolle (Transports optimieren) eignet sich für Consumer-Anwendungen mit Identifier-First-Abläufen und nativen mobilen Apps.

Identifier-First ermöglicht Transportoptimierung: Wenn Benutzer zuerst ihre Kennung angeben, wird das Transport-Handling 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 Konto-Enumeration.

Für Unternehmen / Maximale Flexibilität:

• Verwenden Sie leeres allowCredentials, um alle Authentifikatortypen zu unterstützen
• Vertrauen Sie den vom Authentifikator bereitgestellten Transports
• Akzeptieren Sie, dass Benutzern mehr Authentifizierungsoptionen angezeigt werden
• Einfachere Implementierung, breitere Kompatibilität

Für Consumer-Anwendungen / Native Apps:

• Implementieren Sie einen Identifier-First-Authentifizierungsablauf
• Benutzer-Nudges (Post-Login, automatische Aufforderungen): Verwenden Sie authenticatorAttachment: "platform" für sofortige Authentifizierung mit hoher Erfolgsrate
• Web-Kontoeinstellungen: Erlauben Sie die Erstellung ohne authenticatorAttachment für Power-User, die Sicherheitsschlüssel benötigen
• Verwenden Sie allowCredentials mit spezifischen Anmeldeinformationen und optimierten Transports
• Native Apps: Aktivieren Sie preferImmediatelyAvailableCredentials für die stille Authentifizierung
• Füllen Sie leere Arrays unter iOS mit ["hybrid", "internal"]
• Web-Authentifizierung: Unterstützen Sie alle Transports einschließlich Sicherheitsschlüsseln
• Filtern Sie hybrid auf Mobilgeräten, um QR-Codes gegebenenfalls zu verhindern
• Überlegene UX mit optimierten Authentifizierungsoptionen bei gleichzeitiger Beibehaltung der Kompatibilität

Für Plattformen, die bereits Identifier-First-Abläufe haben:

• Die Konto-Enumeration ist ohnehin kein Thema
• Der auf Verbraucher zugeschnittene Ansatz passt natürlich zur bestehenden UX
• Die Transportoptimierung bietet sofortige UX-Vorteile
• Empfohlener Ansatz für die meisten Consumer-Anwendungen

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

1. Persistieren Sie Transports genau so, wie sie bei der Registrierung empfangen wurden
2. Entscheiden Sie über Ihre Gesamtstrategie (maximale Flexibilität vs. auf Verbraucher zugeschnitten)
3. Falls auf Verbraucher zugeschnitten: Implementieren Sie den Identifier-First-Ablauf und optimieren Sie Transports
4. Behandeln Sie leere Arrays unter iOS entsprechend Ihrer gewählten Strategie
5. Testen Sie gründlich über Web, native iOS- und native Android-Plattformen hinweg

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 das Transport-Handling mit Ihrer breiteren Authentifizierungsstrategie in Einklang bringen, stellt sicher, dass Ihre Passkey-Implementierung robust bleibt und im Zuge der Reifung des Ökosystems hervorragende Benutzererlebnisse bietet.

Über Corbado

Corbado ist die Passkey 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 →

iOS AuthenticationServices hält Transportinformationen für Plattform-Authentifikatoren wie iCloud-Schlüsselbund zurück und gibt gemäß den Datenschutzbestimmungen der WebAuthn-Spezifikation leere Arrays zurück. Sicherheitsschlüssel unter iOS stellen Transportdaten wie ["usb"] oder ["nfc"] bereit. Relying Parties sollten alle Transports als Hinweise und nicht als maßgebliche Garantien für Fähigkeiten behandeln.

cable ist eine veraltete Terminologie, die synonym zu hybrid verwendet wird und für caBLE (cloud-assisted Bluetooth Low Energy) steht. Beide beschreiben die geräteübergreifende Authentifizierung, z. B. das Scannen eines QR-Codes zur Authentifizierung einer Desktop-Sitzung mithilfe eines Telefons. hybrid ist der aktuelle Begriff, der in WebAuthn Level 3 eingeführt wurde und in neuen Implementierungen verwendet werden sollte.

Setzen Sie bei Consumer-Anwendungen, die Identifier-First-Abläufe verwenden, die Transports explizit auf ["hybrid", "internal"] für iOS-Plattform-Authentifikatoren, die bei der Registrierung leere Arrays zurückgegeben haben. Dadurch wird verhindert, dass in der Authentifizierungs-UI Eingabeaufforderungen für USB- und NFC-Sicherheitsschlüssel angezeigt werden. Die spezifikationskonforme Alternative besteht darin, Arrays leer zu lassen oder die Eigenschaft transports ganz wegzulassen.

Das Entfernen des Transports hybrid auf Mobilgeräten verhindert QR-Code-Aufforderungen, wenn Benutzer sich bereits auf einem Gerät befinden, auf dem sich ihre Passkeys befinden. Transportmanipulationen führen jedoch zu inkonsistenten Ergebnissen: Einige Plattformen zeigen QR-Codes an, selbst wenn hybrid ausgeschlossen ist, andere verbergen sie unabhängig davon. Testen Sie immer über Zielplattformen hinweg und stellen Sie Fallback-Authentifizierungsmethoden bereit, um Sackgassen zu vermeiden.

Ein leeres allowCredentials-Array unterstützt alle Authentifikatortypen, einschließlich Sicherheitsschlüssel und geräteübergreifender Authentifizierung, verringert jedoch die Transportrelevanz und kann Benutzern mehrere gleichzeitige Optionen präsentieren. Die Bestückung mit spezifischen Benutzeranmeldeinformationen macht die Handhabung von Transporten für die Optimierung der Benutzeroberfläche entscheidend, sodass Identifier-First-Abläufe QR-Codes auf Mobilgeräten filtern und Sicherheitsschlüssel-Aufforderungen in Endverbraucher-Kontexten ausblenden können.