Transports WebAuthn : transports internes et hybrides

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

Remarque : selon la spécification WebAuthn, un champ "transports" vide signifie que tous les transports sont pris en charge.

Lors de l'implémentation des passkeys sur différentes plateformes, les développeurs font face à une décision importante :

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

La réponse réside dans la compréhension des transports WebAuthn — un détail technique qui détermine comment les authentifiants communiquent avec les parties de confiance. Bien que les transports semblent simples en théorie, leur implémentation varie considérablement entre les navigateurs web, les applications natives iOS et les applications natives Android, notamment en ce qui concerne la gestion des transports internes et hybrides.

Cet article examine le fonctionnement des transports WebAuthn sur différentes plateformes et présente deux approches distinctes pour gérer les transports internes et hybrides, chacune avec ses propres compromis.

Cet article couvre :

1. Les transports WebAuthn : internes, hybrides et les authentifiants de plateforme sur le web, iOS et Android
2. Deux approches : gestion des transports internes et hybrides conforme aux spécifications ou optimisée
3. Bonnes pratiques et recommandations pour l'implémentation de l'authentification cross-device

Les transports WebAuthn définissent les méthodes de communication entre les authentifiants 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, comme les YubiKeys ou d'autres jetons de sécurité FIDO2.

nfc : permet la communication avec des authentifiants via Near Field Communication, autorisant les utilisateurs à simplement approcher leurs clés de sécurité ou appareils compatibles NFC.

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

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

hybrid : permet l'authentification cross-device, généralement lorsqu'un utilisateur scanne un QR code pour s'authentifier entre plusieurs appareils, par exemple en utilisant un téléphone pour s'authentifier sur un navigateur de bureau, ou vice versa. Ce transport peut déclencher des invites de QR code sur les appareils de bureau et mobiles, ce qui n'est pas toujours souhaitable selon le contexte. Remarque : hybrid a été ajouté dans WebAuthn de niveau 3.

internal : l'authentifiant est intégré à l'appareil lui-même, comme le Trousseau iCloud (vérifié via Face ID ou Touch ID) sur les iPhones, Windows Hello sur les PC, ou Google Password Manager sur les appareils Android. Ce sont des authentifiants de plateforme.

Lorsqu'un passkey est créé, l'authentifiant signale les transports qu'il prend en charge. Cette information est envoyée à la partie de confiance (votre backend), qui doit la conserver avec les informations d'identification. Lors de l'authentification, la partie de confiance renvoie ces transports au client dans la liste allowCredentials, aidant le navigateur ou la plateforme à déterminer quelles méthodes d'authentification proposer à l'utilisateur.

La gestion des transports diffère considérablement d'une plateforme à l'autre, créant les défis de compatibilité que rencontrent les développeurs.

Les navigateurs reçoivent les informations de transport des authentifiants et les respectent lors des flux d'authentification. Lorsque vous créez un passkey dans Chrome, Safari ou Edge, le gestionnaire d'identifiants du navigateur fournit des données de transport qui varient en fonction de l'authentifiant sous-jacent :

Authentifiants de plateforme : Windows Hello fournit uniquement ["internal"], reflétant sa nature liée à l'appareil. Cependant, lorsque Chrome utilise Google Password Manager comme authentifiant, il fournit ["internal", "hybrid"] car Google Password Manager prend en charge l'authentification cross-device 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'identifiants synchronisés dans le cloud : le Trousseau iCloud dans Safari et Google Password Manager dans Chrome fournissent généralement ["internal", "hybrid"] pour prendre en charge les flux d'authentification locaux et cross-device.

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

Documentation : Spécification WebAuthn du W3C

L'API Credential Manager d'Android se comporte de manière similaire aux navigateurs web. Lors de la création de passkeys dans des applications Android natives, le Credential Manager fournit des informations de transport qui reflètent le comportement du web : les authentifiants 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 se fier à ces informations sans traitement spécial.

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'authentifiant :

Authentifiants de plateforme (Trousseau iCloud, vérifié via Face ID ou Touch ID) : renvoient souvent des tableaux de transports vides lors de la création de passkeys. Cela ne signifie pas que le passkey n'a pas de capacités de transport, mais simplement qu'iOS ne les signale pas explicitement. Selon la norme WebAuthn, l'omission des transports signifie que n'importe quel transport est acceptable, donc l'authentification hybride fonctionnera toujours.

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

Documentation : AuthenticationServices d'Apple

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 : utiliser les transports exactement tels que fournis par l'authentifiant lors de l'enregistrement des identifiants, et les renvoyer sans modification lors de l'authentification.

Implémentation : lorsqu'un passkey est créé, conservez le tableau transports de la réponse de l'authentifiant. 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 des plateformes.
• Fiabilité des clés 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 invalides : évite de proposer des méthodes d'authentification qui ne sont réellement pas prises en charge, par exemple, ne déclenchera pas de QR codes pour les identifiants Windows Hello.

Inconvénients :

• Comportement du tableau vide d'iOS : les authentifiants de plateforme sur iOS renvoient des transports vides, ce qui, selon la spécification, signifie "n'importe quel transport". Cela peut afficher toutes les options d'authentification, y compris les clés de sécurité.
• Peut afficher des options non désirées : pourrait présenter des options de clés 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 différentes options d'authentification pour le même compte.

Idéal pour : les applications privilégiant la conformité aux normes, les environnements d'entreprise avec divers types d'authentifiants.

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érons ces scénarios d'optimisation courants :

Problème : les authentifiants de plateforme iOS renvoient des tableaux de transports vides. Si on les laisse vides ou si les backends les remplissent, les utilisateurs pourraient voir des invites de clés de sécurité (USB, NFC) à côté des options de la plateforme, ce qui crée de la confusion dans les applications grand public.

Solution : définissez explicitement les transports à ["hybrid", "internal"] pour les authentifiants de plateforme iOS. Cela garantit que seules l'authentification de la plateforme et les flux cross-device sont proposés, masquant les options de clés de sécurité.

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

Résultat : une interface utilisateur d'authentification épurée, sans invites de clés de sécurité pour les passkeys créés sur iOS.

Problème : lors de l'authentification sur des appareils mobiles, afficher des QR codes pour l'authentification cross-device crée une mauvaise expérience utilisateur. Les utilisateurs sont déjà sur un appareil mobile où leurs passkeys sont disponibles.

Solution : supprimez le transport hybrid lorsque l'utilisateur s'authentifie depuis un appareil mobile, ne laissant que ["internal"].

// Lors de la construction de 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 les invites de QR code inutiles.

⚠️ 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 QR codes même lorsque hybrid est exclu des transports.
• D'autres masquent les QR codes même lorsque hybrid est inclus.
• Le comportement varie considérablement entre Chrome, Edge, Safari et Firefox sur Windows, macOS et iOS.

Risque d'impasses : un filtrage trop restrictif des transports peut créer des impasses d'authentification où les utilisateurs ne peuvent plus se connecter du tout. Par exemple, supprimer hybrid pourrait empêcher des scénarios légitimes d'authentification cross-device où un utilisateur a besoin de s'authentifier depuis un appareil emprunté. Fournissez toujours des méthodes d'authentification de secours et testez minutieusement sur toutes vos plateformes cibles avant de déployer des optimisations de transport.

Ce sont des pistes d'optimisation : WebAuthn fournit d'autres mécanismes pour optimiser l'expérience utilisateur de l'authentification au-delà de la manipulation des transports, comme les hints.

Le comportement des transports est imprévisible : l'authentification cross-device (CDA) via le transport hybrid présente un comportement incohérent selon les combinaisons de navigateurs et de systèmes d'exploitation. Des tests en conditions réelles 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 : lorsque vous contrôlez explicitement les transports, vous devez tenir compte des différences entre les plateformes :

• iOS : envoie des tableaux vides pour les authentifiants de plateforme, ce qui nécessite de les remplir.
• Windows Hello : doit rester ["internal"] uniquement ; l'ajout de hybrid déclenche des QR codes non désirés.
• Web & Android : fournissent généralement des informations de transport précises.
• Variations de la CDA : les invites de QR code peuvent apparaître ou disparaître indépendamment de la présence de hybrid dans le tableau des transports.

Compréhension de bout en bout requise : contrôler explicitement les transports signifie prendre 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 :

• Expérience utilisateur 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 d'iOS : définit explicitement les transports là où iOS n'en fournit aucun.
• Optimisation contextuelle : 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 d'interface utilisateur cohérent. 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 trop restrictif des transports peut empêcher complètement les utilisateurs de s'authentifier, en particulier dans les scénarios cross-device.
• S'écarte de la spécification : s'éloigne des recommandations de la spécification, ce qui pourrait causer des problèmes avec les futurs changements de plateforme.
• Charge de maintenance : nécessite une logique spécifique à la plateforme et des mises à jour continues à mesure que les plateformes évoluent.
• Complexité : il faut gérer manuellement les tableaux vides d'iOS, les contraintes de Windows Hello et d'autres particularités de plateforme.
• Charge de tests : chaque règle d'optimisation doit être vérifiée sur toutes les combinaisons de plateformes.

Idéal pour : les applications grand public avec des exigences d'expérience utilisateur spécifiques, les équipes disposant des ressources pour maintenir une logique spécifique à la plateforme, les scénarios privilégiant des flux d'authentification simplifiés plutôt qu'une stricte conformité aux spécifications.

La gestion des transports WebAuthn n'est pas un élément isolé. C'est une pièce de votre stratégie globale d'implémentation des passkeys. Deux approches courantes émergent dans les déploiements en production, chacune ayant des implications différentes pour l'utilisation des transports internes et hybrides.

Cette approche privilégie la flexibilité et la conformité aux standards, permettant aux utilisateurs de s'authentifier avec n'importe quel authentifiant compatible.

Caractéristiques de l'implémentation :

• Interface d'authentification : un bouton passkey apparaît à côté des options de connexion existantes (nom d'utilisateur/mot de passe).
• allowCredentials : défini sur un tableau vide [], permettant à n'importe quel identifiant de correspondre.
• Types d'authentifiants : clés de sécurité, authentification cross-device (QR codes), authentifiants de plateforme, tous pris en charge.
• Exigences des applications natives : doivent 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 QR code.
• Gestion des transports : doit prendre en charge tous les types de transport, y compris ceux des clés de sécurité (usb, nfc, ble).

Implications sur les transports :

Avec un allowCredentials vide, les transports deviennent moins critiques lors de l'authentification : la plateforme affiche toutes les options disponibles. Cependant, cela signifie que les utilisateurs peuvent voir simultanément des invites de clés de sécurité, des QR codes 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é d'authentification maximale.

Cette approche optimise l'expérience utilisateur pour le grand public en limitant la création de passkeys aux authentifiants de plateforme et en utilisant des flux "identifier-first" (identifiant d'abord).

Caractéristiques de l'implémentation :

• Création de passkey : seuls les authentifiants de plateforme sont autorisés via authenticatorAttachment: "platform".
• Flux d'authentification : identifier-first ; les utilisateurs saisissent leur e-mail/nom d'utilisateur avant l'authentification.
• allowCredentials : rempli avec les identifiants spécifiques de l'utilisateur (non vide) une fois que l'identifiant est connu.
• Types d'authentifiants : authentifiants de plateforme et authentification cross-device ; les clés de sécurité sont généralement exclues.
• Optimisation des applications natives : peut utiliser preferImmediatelyAvailableCredentials, qui exclut par définition les clés de sécurité et l'authentification cross-device.
• Authentification cross-device : disponible sur le web ; non disponible lors de l'utilisation de preferImmediatelyAvailableCredentials dans les applications natives, mais ce scénario est rare (les utilisateurs ont généralement des passkeys sur l'appareil qu'ils utilisent).
• Gestion des transports : axée uniquement sur les transports internal et hybrid.

Implications sur les transports :

Étant donné que allowCredentials contient des identifiants spécifiques avec leurs transports, la gestion des transports devient cruciale.

Idéal pour : les applications grand public, les applications mobiles natives, les scénarios privilégiant une expérience utilisateur simplifiée plutôt que la flexibilité des authentifiants, les plateformes où les flux identifier-first existent déjà.

Pour les plateformes qui révèlent 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 au grand public s'aligne naturellement. Une fois que l'utilisateur a fourni son identifiant :

1. Le backend recherche les passkeys existants.
2. Il renvoie allowCredentials avec les identifiants spécifiques et leurs transports.
3. La plateforme peut optimiser l'interface d'authentification en fonction des transports.
4. Pas de risque supplémentaire d'énumération de comptes (l'identifiant a déjà été 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 identifiants.

Recommandation : pour les plateformes qui utilisent déjà des flux "identifier-first" ou où l'énumération de comptes n'est pas une préoccupation, l'approche adaptée au grand public avec une gestion explicite des transports offre une expérience utilisateur supérieure, en particulier dans les applications mobiles natives où preferImmediatelyAvailableCredentials permet une authentification biométrique fluide.

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

Conserver les transports lors de l'enregistrement : stockez toujours le tableau transports de la réponse de l'authentifiant avec l'ID de l'identifiant et la clé publique. Ces données sont essentielles pour les flux d'authentification.

Gérer les tableaux vides avec élégance : lorsque vous recevez un tableau de transports vide des authentifiants de plateforme iOS :

• Approche conforme aux spécifications : laissez le champ vide ou omettez la propriété transports, ce qui signifie que "n'importe quel transport" est acceptable.
• Approche d'optimisation : remplissez-le avec ["internal", "hybrid"] pour contrôler les options d'authentification affichées.

Tester sur toutes les plateformes cibles : créez une matrice de tests couvrant toutes les combinaisons :

• Enregistrement : Web, iOS Natif, Android Natif
• Authentification : Web, iOS Natif, Android Natif
• Vérifiez que les QR codes apparaissent quand c'est attendu et sont masqués quand ce n'est pas approprié.

Comprendre la différence entre un tableau vide et une propriété manquante : un tableau transports vide [] et une propriété transports manquante sont généralement traités comme signifiant que "n'importe quel transport est acceptable" selon la spécification. Cependant, les détails d'implémentation varient d'une plateforme à l'autre.

Surveiller les changements de plateforme : les implémentations de WebAuthn évoluent. Apple, Google et Microsoft mettent régulièrement à jour le comportement de leurs authentifiants. 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 cross-device. Votre stratégie de gestion des transports doit s'aligner sur votre approche globale d'implémentation des passkeys et sur vos plateformes cibles.

Les décisions sur les transports s'inscrivent dans une stratégie plus large : la manière dont vous gérez les transports dépend de si vous visez une flexibilité maximale (avec allowCredentials vide) ou une expérience utilisateur optimisée pour le grand public (avec des flux "identifier-first" et des identifiants spécifiques). Cette dernière approche rend les transports essentiels pour l'optimisation.

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

Deux approches valides pour les transports : l'approche conforme aux spécifications (faire confiance aux transports de l'authentifiant) 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.

Les flux "Identifier-First" permettent l'optimisation des transports : lorsque les utilisateurs fournissent d'abord leur identifiant, la gestion des transports devient un puissant outil d'expérience utilisateur. Vous pouvez empêcher les QR codes non désirés sur mobile, masquer les options de clés de sécurité et simplifier l'authentification, sans préoccupations supplémentaires d'énumération de comptes.

Pour l'entreprise / flexibilité maximale :

• Utilisez un allowCredentials vide pour prendre en charge tous les types d'authentifiants.
• Faites confiance aux transports fournis par l'authentifiant.
• 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".
• Limitez-vous aux authentifiants de plateforme (authenticatorAttachment: "platform").
• Utilisez allowCredentials avec des identifiants spécifiques et des transports optimisés.
• Activez preferImmediatelyAvailableCredentials dans les applications natives.
• Remplissez les tableaux vides d'iOS avec ["hybrid", "internal"].
• Filtrez hybrid sur les appareils mobiles pour empêcher les QR codes.
• Expérience utilisateur supérieure avec des options d'authentification simplifiées.

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

• L'énumération de comptes n'est déjà plus un problème.
• L'approche adaptée au grand public s'aligne naturellement avec l'expérience utilisateur existante.
• L'optimisation des transports offre des avantages immédiats en matière d'expérience utilisateur.
• Approche recommandée pour la plupart des applications grand public.

Commencez par être conforme aux spécifications, puis optimisez en fonction de votre stratégie :

1. Conservez les transports exactement tels que reçus lors de l'enregistrement.
2. Décidez de votre stratégie globale (flexibilité maximale vs. adaptée au grand public).
3. Si vous choisissez l'approche adaptée au grand public : implémentez un flux "identifier-first" et optimisez les transports.
4. Gérez les tableaux vides d'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 comme WebAuthn Level 3 introduisent de nouvelles capacités. Construire des systèmes flexibles qui alignent la gestion des transports avec votre stratégie d'authentification globale garantit que votre implémentation de passkeys reste robuste et offre d'excellentes expériences utilisateur à mesure que l'écosystème mûrit.