Transports WebAuthn : transport interne et hybride

Livre blanc Passkey entreprise. Conseils pratiques, modèles de déploiement et KPIs pour les programmes passkeys.

Obtenir le livre blanc

Note : Selon la spécification WebAuthn, une séquence de transports vide signifie que les informations de transport sont indisponibles ou retenues pour des raisons de confidentialité. Les navigateurs considèrent souvent que tous les transports sont potentiellement possibles.

Lors de l'implémentation de clés d'accès sur plusieurs plateformes, les développeurs sont confrontés à une décision importante :

• Comment devez-vous gérer les transports WebAuthn, en particulier les transports internes et hybrides, pour garantir des expériences d'authentification multi-appareils optimales ?

La réponse réside dans la compréhension des transports WebAuthn, un détail technique qui détermine comment les authentificateurs communiquent avec les parties utilisatrices. Bien que les transports semblent simples en théorie, leur mise en œuvre varie considérablement selon les navigateurs web, les applications natives iOS et les applications natives Android, en particulier en ce qui concerne la gestion des transports interne et hybride.

Cet article examine le fonctionnement des transports WebAuthn sur différentes plateformes et présente deux approches distinctes pour gérer les transports interne et hybride, chacune ayant ses propres avantages et inconvénients.

Cet article couvre :

1. Les transports WebAuthn : authentificateurs internes, hybrides et de plateforme sur le web, iOS et Android
2. Deux approches : gestion des transports interne et hybride conforme aux spécifications vs optimisée
3. Les meilleures pratiques et recommandations pour l'implémentation de l'authentification multi-appareils

Les transports WebAuthn définissent les méthodes de communication entre les authentificateurs et les appareils clients. La spécification WebAuthn de niveau 3 définit six types de transport :

usb : Utilisé par les clés de sécurité matérielles qui se connectent via des ports USB, telles que les YubiKeys ou d'autres jetons de sécurité FIDO2.

nfc : Permet la communication avec les authentificateurs via la communication en champ proche (Near Field Communication), ce qui permet aux utilisateurs de présenter leurs clés de sécurité ou leurs appareils compatibles NFC.

ble : Facilite l'authentification via Bluetooth Low Energy, permettant une communication sans fil avec des authentificateurs externes.

smart-card : Utilisé pour les lecteurs de cartes à puce, permettant l'authentification via des cartes à puce.

hybrid : Permet l'authentification multi-appareils, généralement lorsqu'un utilisateur scanne un code QR pour authentifier une session de bureau à l'aide d'un téléphone, ou vice versa. Ce transport peut déclencher des invites de code QR sur les ordinateurs de bureau et les appareils mobiles, ce qui n'est pas toujours souhaitable selon le contexte. Remarque : hybrid a été ajouté dans le niveau 3 de WebAuthn.

internal : L'authentificateur est intégré à l'appareil lui-même, comme le Trousseau iCloud (vérifié via Face ID ou Touch ID) sur les iPhone, Windows Hello sur les PC ou le Gestionnaire de mots de passe Google sur les appareils Android. Ce sont des authentificateurs de plateforme.

Lorsqu'une clé d'accès est créée, l'authentificateur signale les transports qu'il prend en charge. Ces informations sont envoyées à la partie utilisatrice (votre backend), qui doit les conserver avec les informations d'identification. Lors de l'authentification, la partie utilisatrice renvoie ces transports au client dans la liste allowCredentials, ce qui aide le navigateur ou la plateforme à déterminer les méthodes d'authentification à proposer à l'utilisateur.

La gestion des transports diffère considérablement d'une plateforme à l'autre, ce qui crée les défis de compatibilité auxquels les développeurs sont confrontés.

Les navigateurs reçoivent les informations de transport des authentificateurs et les respectent lors des flux d'authentification. Lorsque vous créez une clé d'accès dans Chrome, Safari ou Edge, le gestionnaire d'informations d'identification du navigateur fournit des données de transport qui varient en fonction de l'authentificateur sous-jacent :

Authentificateurs de plateforme : Windows Hello fournit uniquement ["internal"], ce qui reflète sa nature liée à l'appareil. Cependant, lorsque Chrome utilise le Gestionnaire de mots de passe Google comme authentificateur, il fournit ["internal", "hybrid"] car le Gestionnaire de mots de passe Google prend en charge l'authentification multi-appareils via les téléphones Android.

Clés de sécurité matérielles : Fournissent des transports spécifiques comme ["usb", "nfc"] en fonction de leurs capacités réelles.

Gestionnaires d'informations d'identification synchronisés dans le cloud : Le Trousseau iCloud dans Safari et le Gestionnaire de mots de passe Google dans Chrome fournissent généralement ["internal", "hybrid"] pour prendre en charge à la fois les flux d'authentification locaux et multi-appareils.

Ces informations circulent de manière fiable dans les contextes web, bien que les transports spécifiques dépendent de l'authentificateur sélectionné par le navigateur pour le stockage des informations d'identification.

Documentation : Spécification W3C WebAuthn

L'API Credential Manager d'Android se comporte de la même manière que les navigateurs web. Lors de la création de clés d'accès dans des applications Android natives, le Credential Manager fournit des informations de transport qui reflètent le comportement web : les authentificateurs de plateforme signalent leurs capacités avec précision et le système gère les données de transport de manière cohérente. Les développeurs Android peuvent s'appuyer sur ces informations sans gestion particulière.

Documentation : Android Credential Manager

iOS présente une situation plus complexe. Le framework AuthenticationServices d'Apple gère les transports différemment selon le type d'authentificateur :

Authentificateurs de plateforme (Trousseau iCloud, vérifié via Face ID ou Touch ID) : Renvoient souvent des tableaux de transport vides lors de la création d'une clé d'accès. Cela indique que les informations de transport sont indisponibles ou retenues pour des raisons de confidentialité : selon la spécification WebAuthn, les agents utilisateurs peuvent renvoyer des séquences vides lorsque les informations de transport sont inconnues ou pour préserver la confidentialité. Les parties utilisatrices doivent considérer les transports comme des indications plutôt que comme des garanties.

Clés de sécurité : Fournissent des informations de transport (par ex., ["usb"], ["nfc"]) lorsqu'elles sont utilisées avec des appareils iOS, suivant le modèle attendu.

Documentation : Apple AuthenticationServices

Les données de production réelles des applications web et natives révèlent les modèles de transport suivants, classés par fréquence. Notez que ces répartitions sont influencées par les spécificités de l'implémentation et la démographie des clients (utilisation mobile vs bureau, disponibilité d'applications natives), mais elles fournissent des informations précieuses sur l'utilisation typique des transports :

Points clés :

Les authentificateurs de plateforme dominent : La grande majorité des clés d'accès utilisent le transport internal, souvent associé à hybrid pour la prise en charge de l'authentification multi-appareils. Cela reflète l'orientation grand public vers les authentificateurs de plateforme (Trousseau iCloud, Gestionnaire de mots de passe Google).

Les tableaux vides sont courants : Les applications natives iOS renvoient fréquemment des tableaux de transport vides pour les authentificateurs de plateforme, ce qui représente une part importante des informations d'identification en production. Comme indiqué à la section 2.2.3, cela indique des informations de transport indisponibles plutôt qu'une prise en charge complète des transports.

Les clés de sécurité sont rares : Les clés de sécurité matérielles (usb, nfc) représentent une infime fraction des clés d'accès de production, ce qui indique qu'elles sont principalement utilisées dans des scénarios d'entreprise ou de haute sécurité plutôt que dans des applications grand public.

Il existe des variations d'ordre : L'ordre des transports dans les tableaux (["internal", "hybrid"] vs ["hybrid", "internal"]) varie selon la plateforme et l'implémentation de l'authentificateur, mais n'a aucune différence fonctionnelle : les deux indiquent la prise en charge des mêmes méthodes de transport.

Terminologie héritée : L'identifiant de transport cable apparaît occasionnellement dans d'anciennes implémentations et est synonyme de hybrid (caBLE = cloud-assisted Bluetooth Low Energy, le nom d'origine du transport hybride).

Cette répartition renforce l'importance de gérer correctement les transports internal et hybrid, car ils représentent l'écrasante majorité des implémentations de clés d'accès dans le monde réel.

La disponibilité du transport indique ce que les authentificateurs signalent, et non si le flux résultant aboutit. L'analyse de l'achèvement de l'authentification multi-appareils du Corbado Passkey Benchmark 2026 mesure l'achèvement du transport hybrid au premier trimestre 2026 à 60-78 % sur le web Windows et à 66-86 % sur le web macOS au global, se divisant en 79-98 % (Win) / 83-98 % (macOS) pour les incitations sur le même appareil contre 52-67 % (Win) / 59-76 % (macOS) pour les flux identifier-first. Considérez hybrid comme le transport dont le coût est le plus élevé dans la logique de routage et privilégiez les flux qui maintiennent l'utilisateur sur l'appareil contenant l'information d'identification.

Le même authentificateur signale souvent des modèles de transport différents en fonction de la plateforme, de la version et du contexte d'implémentation. Cette variation est normale et attendue :

Le Trousseau iCloud présente trois modèles :

• ["internal", "hybrid"] - Le plus courant, typiquement depuis les navigateurs web
• [] (tableau vide) - Très courant, depuis les applications natives iOS
• ["hybrid", "internal"] - Moins courant, variation d'ordre
• ["internal"] ou ["hybrid"] seul - Cas particuliers rares

Le Gestionnaire de mots de passe Google présente le plus de variations :

• ["hybrid", "internal"] - Modèle le plus courant
• ["internal", "hybrid"] - Ordre alternatif courant
• ["internal", "cable"] - Implémentations héritées (cable = ancien terme pour hybride)
• [] (tableau vide) - Depuis certains contextes natifs
• Transports uniques rarement

Windows Hello est le plus constant :

• ["internal"] - Modèle dominant (lié à l'appareil par conception)

Les gestionnaires de mots de passe comme 1Password, Bitwarden, Dashlane et LastPass présentent tous des modèles de variation similaires :

• Les deux ordres ["internal", "hybrid"] et ["hybrid", "internal"]
• Tableaux vides [] depuis les contextes d'application native
• Occasionnellement juste ["internal"]

Samsung Pass (écosystème Android) utilise principalement :

• ["hybrid", "internal"] et ["internal", "hybrid"] - Les deux ordres sont courants

Différences de plateforme : Le même authentificateur se comporte différemment sur le web vs le natif, iOS vs Android, ou Windows vs macOS.

Évolution des versions : Le signalement des transports a évolué au fil du temps. Les anciennes versions peuvent utiliser cable au lieu de hybrid, ou signaler des combinaisons différentes.

Choix d'implémentation : Certains authentificateurs privilégient internal en premier, d'autres hybrid. L'ordre n'a aucun impact fonctionnel mais varie selon l'implémentation.

Sensibilité au contexte : Les applications natives, en particulier sur iOS, reçoivent souvent des tableaux vides, même de la part d'authentificateurs qui signalent des transports complets dans les contextes web.

À retenir : Ne présumez pas que les tableaux de transport seront cohérents pour un authentificateur donné. Concevez votre implémentation pour gérer toutes les variations avec élégance, en vous concentrant sur la présence de transports spécifiques plutôt que sur une correspondance exacte des tableaux.

Les développeurs ont le choix : suivre strictement la spécification ou optimiser les transports internes et hybrides pour l'expérience utilisateur. Chaque approche a ses avantages et ses inconvénients.

Cette approche s'aligne sur la spécification WebAuthn : utilisez les transports exactement tels qu'ils sont fournis par l'authentificateur lors de l'enregistrement des informations d'identification, et renvoyez-les inchangés lors de l'authentification.

Implémentation : Lorsqu'une clé d'accès est créée, conservez le tableau transports de la réponse de l'authentificateur. Lors de l'authentification, incluez ces transports exacts dans la liste allowCredentials :

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

Avantages :

• Conformité aux spécifications : Suit précisément les normes WebAuthn, garantissant la compatibilité avec les futures mises à jour de la plateforme.
• Fiabilité de la clé de sécurité : Fonctionne parfaitement pour les clés de sécurité matérielles (YubiKeys, etc.) qui fournissent toujours des informations de transport précises.
• Empêche les options non valides : Évite de proposer des méthodes d'authentification qui ne sont véritablement pas prises en charge (par exemple, ne déclenchera pas de codes QR pour les identifiants Windows Hello).

Inconvénients :

• Comportement de tableau vide sous iOS : Les authentificateurs de plateforme sur iOS renvoient des transports vides, ce qui indique que les informations de transport ne sont pas disponibles ; les plateformes peuvent interpréter cela différemment lorsqu'elles déterminent les options d'authentification à afficher.
• Peut afficher des options indésirables : Pourrait présenter des options de clé de sécurité (USB, NFC) dans des applications grand public où elles ne sont pas attendues.
• Expérience utilisateur incohérente : Différentes plateformes offrent des options d'authentification différentes pour le même compte.

Idéal pour : Les applications privilégiant le respect des normes, les environnements d'entreprise avec divers types d'authentificateurs.

Cette approche donne la priorité à l'expérience utilisateur en modifiant sélectivement les transports internes et hybrides en fonction d'objectifs d'optimisation spécifiques. Plutôt qu'une règle générale, considérez ces scénarios d'optimisation courants :

Problème : Les authentificateurs de plateforme iOS renvoient des tableaux de transport vides. Lorsqu'ils sont laissés vides ou remplis par les backends, les utilisateurs peuvent voir des invites de clé de sécurité (USB, NFC) à côté des options de plateforme, créant de la confusion dans les applications grand public.

Solution : Définissez explicitement les transports sur ["hybrid", "internal"] pour les authentificateurs de plateforme iOS. Cela garantit que seules l'authentification par la plateforme et les flux multi-appareils sont proposés, masquant ainsi les options de clé de sécurité.

// Lors de la persistance des informations d'identification de l'authentificateur de plateforme iOS
if (platform === "iOS" && authenticatorAttachment === "platform") {
    transports = ["hybrid", "internal"];
}

Résultat : Une interface utilisateur d'authentification propre, sans invites de clé de sécurité pour les clés d'accès créées sous iOS.

Problème : Lors de l'authentification sur des appareils mobiles, l'affichage de codes QR pour l'authentification multi-appareils crée une mauvaise UX : les utilisateurs sont déjà sur un appareil mobile avec leurs clés d'accès disponibles.

Solution : Supprimez le transport hybrid lorsque l'utilisateur s'authentifie à partir d'un appareil mobile, en ne laissant que ["internal"].

// Lors de la construction d'allowCredentials pour l'authentification
const transports = isMobileDevice
    ? credentials.transports.filter((t) => t !== "hybrid")
    : credentials.transports;

Résultat : Les utilisateurs mobiles ne voient que les options d'authentification directes, sans invites inutiles de code QR.

⚠️ Attention : La manipulation des transports ne produit pas toujours des résultats cohérents d'une plateforme à l'autre. Des tests approfondis montrent que les combinaisons de navigateurs et de systèmes d'exploitation gèrent les transports différemment :

• Certaines plateformes affichent des codes QR même lorsque hybrid est exclu des transports.
• D'autres masquent les codes QR même lorsque hybrid est inclus.
• Le comportement varie considérablement entre Chrome, Edge, Safari et Firefox sous Windows, macOS et iOS.

Risque d'impasses : Un filtrage des transports trop restrictif peut créer des impasses d'authentification où les utilisateurs ne peuvent pas se connecter du tout. Par exemple, la suppression de hybrid pourrait empêcher des scénarios légitimes d'authentification multi-appareils où un utilisateur doit s'authentifier à partir d'un appareil emprunté. Fournissez toujours des méthodes d'authentification de secours et testez minutieusement sur l'ensemble de vos plateformes cibles avant de déployer des optimisations de transport.

Ce sont des indications d'optimisation : WebAuthn fournit d'autres mécanismes pour optimiser l'UX d'authentification au-delà de la manipulation des transports, tels que les hints.

Le comportement des transports est imprévisible : L'authentification multi-appareils (CDA) via le transport hybrid présente un comportement incohérent selon les combinaisons de navigateurs et de systèmes d'exploitation. Les tests dans le monde réel démontrent que les valeurs de transport ne garantissent pas un comportement d'interface utilisateur spécifique : les plateformes interprètent et gèrent les transports différemment, ce qui entraîne des résultats inattendus.

Complexité spécifique à la plateforme : Lors du contrôle explicite des transports, vous devez tenir compte des différences entre les plateformes :

• iOS : Envoie des tableaux vides pour les authentificateurs de plateforme ; nécessite un remplissage.
• Windows Hello : Doit rester ["internal"] uniquement ; l'ajout de hybrid déclenche des codes QR indésirables.
• Web & Android : Fournissent généralement des informations de transport précises.
• Variations CDA : Les invites de code QR peuvent apparaître ou disparaître indépendamment de la présence de hybrid dans le tableau des transports.

Une compréhension de bout en bout est requise : Contrôler explicitement les transports signifie assumer la responsabilité de l'ensemble du flux. Vous devez comprendre comment chaque combinaison de transport se comporte sur toutes vos plateformes cibles et tester minutieusement. La manipulation des transports peut créer des impasses d'authentification où aucun chemin d'authentification valide n'existe pour les utilisateurs.

Avantages :

• UX sur mesure : Contrôlez exactement quelles options d'authentification les utilisateurs voient dans des contextes spécifiques.
• Résout le problème du tableau vide iOS : Définit explicitement les transports là où iOS n'en fournit aucun.
• Optimisation sensible au contexte : Adaptez l'interface utilisateur d'authentification en fonction du type d'appareil.

Inconvénients :

• Comportement imprévisible : La manipulation des transports ne garantit pas un comportement cohérent de l'interface utilisateur : des tests approfondis montrent que les plateformes interprètent les transports différemment, affichant ou masquant parfois des options indépendamment des valeurs de transport.
• Risque d'impasses d'authentification : Un filtrage des transports trop restrictif peut empêcher les utilisateurs de s'authentifier complètement, en particulier dans des scénarios multi-appareils.
• S'écarte des spécifications : S'éloigne des recommandations des spécifications, ce qui peut causer des problèmes avec les futures modifications de plateforme.
• Fardeau de maintenance : Nécessite une logique spécifique à la plateforme et des mises à jour continues à mesure que les plateformes évoluent.
• Complexité : Doit gérer manuellement les tableaux vides iOS, les contraintes de Windows Hello et d'autres particularités de la plateforme.
• Surcharge de test : Chaque règle d'optimisation nécessite une vérification sur toutes les combinaisons de plateformes.

Idéal pour : Les applications grand public ayant des exigences UX spécifiques, les équipes disposant de ressources pour maintenir une logique spécifique à la plateforme, les scénarios privilégiant des flux d'authentification simplifiés par rapport à une stricte conformité aux spécifications.

La gestion des transports WebAuthn n'existe pas de manière isolée : c'est un élément de votre stratégie globale d'implémentation de clés d'accès. Deux approches courantes émergent dans les déploiements de production, chacune ayant des implications différentes pour l'utilisation des transports internes et hybrides.

Cette approche privilégie la flexibilité et le respect des normes, permettant aux utilisateurs de s'authentifier avec tout authentificateur compatible.

Caractéristiques de l'implémentation :

• Interface d'authentification : Le bouton de clé d'accès apparaît à côté des options de connexion existantes (nom d'utilisateur/mot de passe).
• allowCredentials : Défini sur un tableau vide [], ce qui permet à n'importe quelle information d'identification de correspondre.
• Types d'authentificateurs : Clés de sécurité, authentification multi-appareils (codes QR), authentificateurs de plateforme tous pris en charge.
• Exigences de l'application native : Doit prendre en charge toutes les méthodes d'authentification, y compris les clés de sécurité.
• preferImmediatelyAvailableCredentials : Ne peut pas être utilisé, car il exclut par définition les clés de sécurité et les connexions par code QR.
• Gestion des transports : Doit s'adapter à tous les types de transport, y compris les transports par clé de sécurité (usb, nfc, ble).

Implications pour le transport :

Avec un allowCredentials vide, les transports deviennent moins critiques pendant l'authentification : la plateforme affiche toutes les options disponibles. Cependant, cela signifie que les utilisateurs peuvent voir simultanément des invites de clé de sécurité, des codes QR et des options de plateforme, ce qui peut créer une paralysie décisionnelle dans les applications grand public.

Idéal pour : Les environnements d'entreprise, les applications avec des bases d'utilisateurs diversifiées nécessitant la prise en charge des clés de sécurité, les scénarios privilégiant une flexibilité maximale de l'authentification.

Cette approche s'optimise pour l'UX grand public en restreignant la création de clés d'accès aux authentificateurs de plateforme et en utilisant des flux "identifier-first" (identifiant en premier).

Caractéristiques de l'implémentation :

• Création de clés d'accès : Les incitations initiées par l'utilisateur (invites après connexion, flux de création automatique) utilisent authenticatorAttachment: "platform" pour se concentrer sur les authentificateurs immédiatement disponibles.
• Prise en charge des clés de sécurité : Disponible via les paramètres de compte web sans restriction authenticatorAttachment, permettant aux utilisateurs avancés de sélectionner n'importe quel authentificateur, y compris les clés de sécurité.
• Flux d'authentification : Identifier-first : les utilisateurs saisissent leur e-mail/nom d'utilisateur avant l'authentification.
• allowCredentials : Rempli avec les informations d'identification spécifiques de l'utilisateur (non vide) une fois que l'identifiant est connu.
• Types d'authentificateurs : Authentificateurs de plateforme et authentification multi-appareils prioritaires ; clés de sécurité prises en charge mais non promues dans les flux principaux.
• Optimisation de l'application native : Utilise preferImmediatelyAvailableCredentials pour une authentification silencieuse et instantanée sans invites pour les clés de sécurité ou les codes QR.
• Authentification multi-appareils : Disponible sur le web ; intentionnellement exclue dans les applications natives lors de l'utilisation de preferImmediatelyAvailableCredentials (les utilisateurs s'authentifient généralement sur l'appareil où résident leurs clés d'accès).
• Gestion des transports : Accent principal sur les transports internal et hybrid.

Implications pour le transport :

Étant donné qu'allowCredentials contient des informations d'identification spécifiques avec leurs transports, la gestion des transports devient cruciale pour optimiser les expériences d'authentification.

La réalité des clés de sécurité : Les clés de sécurité représentent une fraction extrêmement faible de l'utilisation des clés d'accès dans les déploiements grand public à grande échelle, principalement des utilisateurs avancés ou des utilisateurs ayant des exigences de sécurité spécifiques. L'approche adaptée aux consommateurs reconnaît cette réalité en prenant en charge les clés de sécurité sans optimiser les flux principaux autour d'elles.

Stratégie de création à deux niveaux : Les implémentations peuvent équilibrer la compatibilité des clés de sécurité avec une UX grand public optimisée via des chemins de création doubles :

• Incitations et invites aux utilisateurs : Les invites après connexion et les flux de création automatique utilisent authenticatorAttachment: "platform", guidant les utilisateurs vers des clés d'accès immédiatement disponibles avec des taux de réussite élevés.
• Paramètres de compte web : Offre la création sans authenticatorAttachment, permettant aux utilisateurs avancés de sélectionner des clés de sécurité, des gestionnaires de mots de passe tiers ou tout authentificateur disponible.

Ce modèle apparaît dans les implémentations majeures : les clés de sécurité sont prises en charge et fonctionnelles via les paramètres, mais les incitations destinées aux utilisateurs optimisent le cas d'utilisation dominant : les authentificateurs de plateforme qui fournissent une authentification instantanée et silencieuse.

Idéal pour : Les applications grand public, les applications mobiles natives, les scénarios privilégiant une UX simplifiée à la flexibilité de l'authentificateur, les plateformes où les flux "identifier-first" existent déjà.

Pour les plateformes qui divulguent déjà l'existence d'un compte ou utilisent des flux "identifier-first" (l'utilisateur saisit son e-mail avant de voir les options de connexion), l'approche adaptée aux consommateurs s'aligne naturellement. Une fois que l'utilisateur a fourni son identifiant :

1. Le backend recherche les clés d'accès existantes.
2. Renvoie allowCredentials avec des informations d'identification spécifiques et leurs transports.
3. La plateforme peut optimiser l'interface utilisateur d'authentification en fonction des transports.
4. Aucun risque supplémentaire d'énumération de compte (identifiant déjà fourni).

Dans ces scénarios, les transports peuvent devenir un outil d'optimisation plutôt qu'une préoccupation de sécurité. Vous pouvez adapter les options d'authentification en fonction du contexte de l'appareil (mobile vs bureau) et des capacités des informations d'identification.

Recommandation : Pour les plateformes qui utilisent déjà des flux identifier-first ou où l'énumération de compte n'est pas un problème, l'approche adaptée aux consommateurs avec une gestion explicite du transport offre une UX supérieure, en particulier dans les applications mobiles natives où preferImmediatelyAvailableCredentials permet une authentification biométrique transparente.

Quelle que soit l'approche que vous choisissez pour gérer les transports internes et hybrides, suivez ces pratiques pour minimiser les problèmes :

Persister les transports lors de l'enregistrement : Stockez toujours le tableau transports de la réponse de l'authentificateur avec l'ID des informations d'identification et la clé publique. Ces données sont essentielles pour les flux d'authentification.

Gérer les tableaux vides de manière appropriée : Lors de la réception d'un tableau de transport vide des authentificateurs de plateforme iOS :

• Conforme aux spécifications : Laissez vide ou omettez la propriété transports : indique que les informations de transport sont indisponibles ; les plateformes détermineront les options disponibles.
• Approche d'optimisation : Remplissez avec ["internal", "hybrid"] pour contrôler les options d'authentification affichées.

Stratégies de transport web vs natif : Différenciez la gestion du transport en fonction du contexte :

• Authentification web : Incluez tous les transports, ce qui permet une prise en charge plus large des authentificateurs, y compris les clés de sécurité via USB/NFC.
• Authentification d'application native : Utilisez preferImmediatelyAvailableCredentials pour une authentification silencieuse ; les transports envoyés tels que stockés.
• Pages de paramètres/gestion : Prenez en charge tous les types d'authentificateurs pour les utilisateurs avancés.

Gérer l'authentification par clé de sécurité : Lorsque les utilisateurs ont enregistré des clés de sécurité :

• Web : Détectez les transports de clés de sécurité dans les informations d'identification stockées et assurez-vous que les flux d'authentification peuvent les accueillir.
• Applications natives : Envisagez de fournir des méthodes d'authentification de secours ou d'orienter les utilisateurs vers le web pour l'authentification par clé de sécurité.
• Approche hybride : Les applications natives optimisent pour les authentificateurs de plateforme tandis que le web prend en charge la flexibilité complète des authentificateurs.

Tester sur toutes les plateformes cibles : Créez une matrice de test couvrant toutes les combinaisons :

• Enregistrement : Web, iOS natif, Android natif.
• Authentification : Web, iOS natif, Android natif.
• Vérifiez que l'authentification silencieuse fonctionne avec preferImmediatelyAvailableCredentials.
• Confirmez que les clés de sécurité fonctionnent dans les flux de paramètres sans authenticatorAttachment.
• Validez que les codes QR n'apparaissent que dans des contextes appropriés.

Comprendre la sémantique du transport : Reconnaître les différences entre les valeurs de transport vides et manquantes :

• Tableau de transports vide [] : Indique que les informations de transport sont indisponibles ou retenues pour des raisons de confidentialité. Les agents utilisateurs peuvent fournir des séquences vides lorsqu'ils ne peuvent pas ou choisissent de ne pas signaler les capacités de transport. Cela ne signifie pas "tous les transports sont pris en charge" ; traitez-les comme des indications lorsque les informations ne sont pas disponibles.
• Propriété transports manquante : Lorsque les transports sont omis des descripteurs d'informations d'identification, les agents utilisateurs déterminent les méthodes d'authentification disponibles en fonction d'autres facteurs. Le contexte compte : entre les réponses d'enregistrement et les options de demande d'authentification, les implications diffèrent.
• Indications de transport (hints) : Selon les spécifications, les transports doivent être considérés comme des indications pour aider les agents utilisateurs à optimiser l'interface utilisateur d'authentification, et non comme des garanties de capacités faisant autorité.

Surveiller les modifications de la plateforme : Les implémentations WebAuthn évoluent. Apple, Google et Microsoft mettent régulièrement à jour les comportements de leurs authentificateurs. Restez informé des changements qui pourraient affecter la gestion des transports.

Les transports WebAuthn, en particulier les transports internes et hybrides, sont des détails techniques ayant un impact pratique significatif sur l'authentification multi-appareils. Votre stratégie de gestion des transports doit s'aligner sur votre approche globale d'implémentation de clés d'accès et sur vos plateformes cibles.

Les décisions de transport s'inscrivent dans une stratégie plus large : La façon dont vous gérez les transports dépend de si vous construisez pour une flexibilité maximale (allowCredentials vide) ou pour l'UX grand public (identifier-first avec des identifiants spécifiques). Cette dernière rend les transports critiques pour l'optimisation.

Les différences de plateforme nécessitent une gestion : Le Web et Android fournissent des informations de transport fiables, tandis que les authentificateurs de plateforme iOS renvoient des tableaux vides. Windows Hello n'envoie que ["internal"]. Comprendre ces différences est essentiel pour les déploiements de production.

Deux approches de transport valides : L'approche conforme aux spécifications (faire confiance aux transports de l'authentificateur) fonctionne bien pour les scénarios d'entreprise et de flexibilité maximale. Le contrôle explicite (optimiser les transports) convient aux applications grand public avec des flux identifier-first et aux applications mobiles natives.

Identifier-First permet l'optimisation des transports : Lorsque les utilisateurs fournissent leur identifiant en premier, la gestion du transport devient un outil UX puissant. Vous pouvez éviter les codes QR indésirables sur mobile, masquer les options de clé de sécurité et rationaliser l'authentification, sans préoccupations supplémentaires liées à l'énumération de comptes.

Pour l'entreprise / Flexibilité maximale :

• Utilisez un allowCredentials vide pour prendre en charge tous les types d'authentificateurs.
• Faites confiance aux transports fournis par l'authentificateur.
• Acceptez que les utilisateurs voient plus d'options d'authentification.
• Implémentation plus simple, compatibilité plus large.

Pour les applications grand public / Applications natives :

• Implémentez un flux d'authentification identifier-first.
• Incitations utilisateur (après connexion, invites automatiques) : Utilisez authenticatorAttachment: "platform" pour une authentification immédiate à haut succès.
• Paramètres de compte web : Autorisez la création sans authenticatorAttachment pour les utilisateurs avancés nécessitant des clés de sécurité.
• Utilisez allowCredentials avec des informations d'identification spécifiques et des transports optimisés.
• Applications natives : Activez preferImmediatelyAvailableCredentials pour une authentification silencieuse.
• Remplissez les tableaux vides iOS avec ["hybrid", "internal"].
• Authentification web : Prenez en charge tous les transports, y compris les clés de sécurité.
• Filtrez hybrid sur les appareils mobiles pour empêcher les codes QR le cas échéant.
• UX supérieure avec des options d'authentification rationalisées tout en maintenant la compatibilité.

Pour les plateformes ayant déjà des flux Identifier-First :

• L'énumération de compte n'est déjà plus un problème.
• L'approche adaptée aux consommateurs s'aligne naturellement sur l'UX existante.
• L'optimisation du transport offre des avantages UX immédiats.
• Approche recommandée pour la plupart des applications grand public.

Commencez par respecter les spécifications, puis optimisez en fonction de votre stratégie :

1. Persistez les transports exactement tels qu'ils sont reçus lors de l'enregistrement.
2. Décidez de votre stratégie globale (flexibilité maximale vs adaptée aux consommateurs).
3. Si adaptée aux consommateurs : implémentez un flux identifier-first et optimisez les transports.
4. Gérez les tableaux vides iOS de manière appropriée pour la stratégie choisie.
5. Testez minutieusement sur les plateformes Web, iOS natif et Android natif.

Le paysage WebAuthn continue d'évoluer. Les fournisseurs de plateformes mettent régulièrement à jour leurs implémentations et des spécifications telles que WebAuthn Level 3 introduisent de nouvelles capacités. La création de systèmes flexibles qui alignent la gestion des transports sur votre stratégie d'authentification plus large garantit que votre implémentation de clés d'accès reste robuste et offre d'excellentes expériences utilisateur à mesure que l'écosystème gagne en maturité.

À propos de Corbado

Corbado est la Passkey Intelligence Platform pour les équipes CIAM qui gèrent l'authentification client à grande échelle. Nous vous montrons ce que les logs IDP et les outils d'analytics génériques ne voient pas : quels appareils, versions d'OS, navigateurs et gestionnaires de credentials prennent en charge les passkeys, pourquoi les enrôlements ne deviennent pas des connexions, où le flux WebAuthn échoue et quand une mise à jour OS ou navigateur casse silencieusement la connexion — le tout sans remplacer Okta, Auth0, Ping, Cognito ni votre IDP interne. Deux produits : Corbado Observe ajoute l'observabilité pour les passkeys et toute autre méthode de connexion. Corbado Connect apporte des passkeys managés avec analytics intégrés (aux côtés de votre IDP). VicRoads gère les passkeys pour plus de 5M d'utilisateurs avec Corbado (+80 % d'activation passkey). Parler à un expert Passkey →

iOS AuthenticationServices retient les informations de transport pour les authentificateurs de plateforme tels que le Trousseau iCloud, renvoyant des tableaux vides conformément aux dispositions de confidentialité de la spécification WebAuthn. Les clés de sécurité sur iOS fournissent des données de transport telles que ["usb"] ou ["nfc"]. Les parties utilisatrices doivent considérer tous les transports comme des indications plutôt que comme des garanties faisant autorité sur la capacité.

cable est une terminologie obsolète synonyme de hybrid, qui signifie caBLE (cloud-assisted Bluetooth Low Energy). Tous deux décrivent l'authentification multi-appareils, comme la numérisation d'un code QR pour authentifier une session de bureau à l'aide d'un téléphone. hybrid est le terme actuel introduit dans le niveau 3 de WebAuthn et doit être utilisé dans les nouvelles implémentations.

Pour les applications grand public utilisant des flux identifier-first, définissez explicitement les transports sur ["hybrid", "internal"] pour les authentificateurs de plateforme iOS qui ont renvoyé des tableaux vides lors de l'enregistrement. Cela empêche les invites de clé de sécurité USB et NFC d'apparaître dans l'interface d'authentification. L'alternative conforme à la spécification consiste à laisser les tableaux vides ou à omettre entièrement la propriété transports.

La suppression du transport hybrid sur mobile empêche les invites de code QR lorsque les utilisateurs sont déjà sur un appareil où résident leurs clés d'accès. Cependant, la manipulation du transport produit des résultats incohérents : certaines plateformes affichent des codes QR même lorsque hybrid est exclu, et d'autres les masquent dans tous les cas. Testez toujours sur l'ensemble des plateformes cibles et fournissez des méthodes d'authentification de secours pour éviter de créer des impasses.

Un tableau allowCredentials vide prend en charge tous les types d'authentificateurs, y compris les clés de sécurité et l'authentification multi-appareils, mais réduit la pertinence du transport et peut présenter aux utilisateurs plusieurs options simultanées. Le remplir avec des informations d'identification utilisateur spécifiques rend la gestion des transports essentielle pour optimiser l'interface utilisateur, permettant aux flux identifier-first de filtrer les codes QR sur mobile et de masquer les invites de clé de sécurité dans les contextes grand public.