Codes QR et Bluetooth pour les passkeys WebAuthn : le transport hybride

Les passkeys remplacent de plus en plus les mots de passe en tant que norme de facto pour l'authentification des utilisateurs. Contrairement aux mots de passe traditionnels, les passkeys sont liés à un écosystème (par exemple, le Trousseau iCloud, le Gestionnaire de mots de passe de Google, Windows Hello ou un gestionnaire de mots de passe comme 1Password ou Dashlane) ; ils ne sont pas conçus pour être mémorisés, mais sont construits pour s'intégrer de manière transparente à vos appareils, offrant une excellente expérience utilisateur prête à l'emploi.

Imaginez que vous êtes loin de votre ordinateur personnel, peut-être sur un terminal public ou l'ordinateur portable d'un ami, et que vous devez vous connecter à votre compte protégé par un passkey. Ce scénario est assez courant et nécessite une méthode d'authentification à la fois sécurisée et pratique, mais avec les passkeys, beaucoup de gens ne savent pas quoi faire, car leur passkey n'est pas immédiatement disponible dans cette situation. L'une des fonctionnalités des passkeys pour vous aider dans une telle situation est la possibilité d'utiliser vos passkeys sur plusieurs appareils grâce à l'utilisation de codes QR et de la technologie Bluetooth. Ce processus est officiellement connu sous le nom de transport hybride dans la spécification WebAuthn (dans les versions précédentes de la spécification, il était appelé Bluetooth Low Energy assisté par le cloud, ou caBLE).

Le processus est simple : vous avez besoin d'un appareil sur lequel vos passkeys sont stockés et qui est capable de prendre des photos, donc très probablement un smartphone ou une tablette. Cet appareil peut ouvrir un tunnel vers le nouvel appareil juste pour cette unique instance d'authentification. Cela maintient non seulement l'intégrité de votre passkey, mais garantit également que l'accès à votre compte sur de nouveaux appareils peut être accordé, où que vous soyez ou quel que soit l'appareil que vous souhaitez utiliser pour vous connecter.

Cependant, cette fonctionnalité d'authentification multiplateforme des passkeys est entourée d'idées fausses et de confusion, tant sur son utilité que sur sa mise en œuvre technique. C'est quelque chose que j'ai encore remarqué récemment lors d'une rencontre locale sur la sécurité informatique. À travers cet article, nous visons à démêler les complexités et à fournir des recommandations pour mettre en œuvre ce flux d'authentification par passkey multiplateforme (transport hybride), afin que vous puissiez offrir la meilleure expérience de connexion à vos utilisateurs.

Les passkeys sont une forme d'authentification des utilisateurs qui remplace le mot de passe traditionnel par une paire de clés cryptographiques publique-privée plus sécurisée et pratique. Cette paire de clés est unique à chaque utilisateur et est utilisée pour vérifier l'identité sans avoir à se soucier de mémoriser des mots de passe complexes.

Les avantages des passkeys sont nombreux par rapport à leurs prédécesseurs, les mots de passe. Ils réduisent considérablement le risque de hameçonnage (phishing), car ils ne peuvent pas être partagés par ruse avec un faux site web. De plus, ils sont immunisés contre les attaques par force brute et par dictionnaire, qui sont des méthodes courantes utilisées pour déchiffrer les mots de passe. Les passkeys sont également plus conviviaux, éliminant le besoin de se souvenir ou de gérer une longue liste de mots de passe.

Les passkeys sont synchronisés dans des comptes cloud, comme ceux gérés par le Gestionnaire de mots de passe de Google ou le Trousseau iCloud d'Apple (Microsoft suivra bientôt avec Windows Hello), ou ceux stockés dans des gestionnaires de mots de passe modernes compatibles avec les passkeys, comme 1Password ou Dashlane. Cependant, il est essentiel de savoir que par défaut, les passkeys sont liés à l'écosystème et à la synchronisation du compte cloud respectif. Les systèmes d'exploitation ne fournissent pas d'interface pour exporter les clés privées et, dans la plupart des appareils, un composant matériel fournit des mesures de sécurité supplémentaires pour éviter tout accès aux clés privées, par exemple la Secure Enclave sur les appareils iOS ou le Trusted Platform Module (TPM) sur les appareils Windows. Seul le fournisseur du système d'exploitation peut synchroniser les passkeys avec d'autres appareils de manière chiffrée (finalement protégée par la biométrie, le code d'accès ou le PIN de l'utilisateur). Les clés privées ne peuvent être restaurées et déchiffrées qu'à l'aide du code d'accès / PIN et seront détruites en cas de trop nombreuses tentatives de connexion infructueuses au compte cloud (par exemple, Apple introduit une limitation de débit pour empêcher les attaques par force brute même depuis une position privilégiée sur le backend cloud ; Google fait de même).

Cette conception inhérente signifie que si les passkeys ne sont pas synchronisés comme décrit, l'accès à vos passkeys sur un nouvel appareil peut poser un défi. C'est précisément pourquoi la méthode de transport hybride pour l'authentification multiplateforme par passkey (transport hybride) avec un code QR et une vérification de proximité Bluetooth existe. Elle fournit un pont sécurisé pour vos passkeys entre les appareils sans avoir besoin de les synchroniser via un compte cloud / gestionnaire de mots de passe, maintenant ainsi le principe que les passkeys peuvent rester uniquement avec l'utilisateur.

L'utilisation de l'authentification par passkey multiplateforme (transport hybride) avec le transport hybride aide à surmonter les problèmes entre appareils, lorsqu'un compte est accessible uniquement via des passkeys. Comme tous les passkeys ne sont pas synchronisés dans des comptes cloud ou des gestionnaires de mots de passe, la nécessité d'une méthode fiable pour accéder aux passkeys sur différents appareils devient essentielle, en particulier lors de la transition vers un nouvel appareil ou lorsqu'un accès est nécessaire sur un appareil partagé.

Pour faciliter l'authentification par passkey multiplateforme (transport hybride), les prérequis matériels suivants existent :

• Prise en charge de WebAuthn : Les appareils doivent prendre en charge WebAuthn. C'est déjà le cas sur 99 % des appareils, selon notre dernière analyse de données sur la préparation aux passkeys.
• Appareil photo pour la lecture de codes QR : Les appareils auront besoin d'un appareil photo capable de scanner des codes QR. La plupart des smartphones modernes sont équipés d'appareils photo dotés de cette fonctionnalité. De plus, l'appareil photo doit avoir des capacités de lecture de QR intégrées (ce que la plupart des appareils ont d'origine). Si votre appareil photo ne le prend pas en charge, un lecteur de QR en ligne est également une bonne option. Sinon, l'installation d'une application de code QR convient également.
• Capacité Bluetooth : Le Bluetooth Low Energy assisté par le cloud (caBLE) est utilisé pour établir une connexion sécurisée basée sur la proximité entre les appareils. Les versions à rechercher sont Bluetooth 4.0 ou supérieur, qui activent l'extension caBLE pour WebAuthn.
• Connexion Internet : Une connexion Internet stable sur les deux appareils doit être en place, car l'échange implique l'ouverture d'un tunnel pour effectuer des étapes de vérification qui nécessitent un transfert de données en temps réel.

Du point de vue logiciel, les exigences suivantes existent :

• Configuration du serveur WebAuthn : Évidemment, vous devez avoir un serveur WebAuthn en place qui gère les clés publiques. Cela implique également de permettre au compte de l'utilisateur d'être lié à plusieurs authentificateurs et de configurer le serveur pour initier la cérémonie d'authentification.
• API Web Bluetooth : Pour la vérification de proximité Bluetooth, vous devrez accéder à l'API Web Bluetooth qui déclenche les capacités Bluetooth de l'appareil depuis un navigateur.
• Prérequis du système d'exploitation : Veuillez consulter le tableau suivant concernant la prise en charge de l'authentification inter-appareils pour différents systèmes d'exploitation en mars 2025. Authentificateur signifie que l'appareil peut servir d'appareil qui détient un passkey (dans notre scénario, le smartphone). Client signifie l'appareil qui crée le code QR et où l'utilisateur essaie de se connecter (dans notre scénario, l'ordinateur de bureau) :

Source : passkeys.dev

Le processus pour utiliser l'authentification par passkey multiplateforme (transport hybride) via un code QR se présente comme suit :

Le code QR pour l'authentification par passkey multiplateforme (transport hybride) est généré lorsqu'un utilisateur tente d'accéder à un service sur un appareil où le passkey enregistré n'est pas présent, mais le service sait que l'utilisateur devrait avoir un passkey. Généralement, un bouton « Scanner le code QR » ou un appel à l'action similaire est fourni dans l'interface d'authentification.

À la demande de l'utilisateur, l'appareil lance la génération d'un code QR. Ce code QR encode un identifiant de session unique et limité dans le temps. Cet identifiant est lié à une session que le serveur d'authentification maintient temporairement, en attendant l'achèvement du processus d'authentification.

L'utilisateur scanne ce code QR avec un appareil où son passkey est disponible. Les mesures de sécurité comprennent :

• Usage unique : L'identifiant de session dans le code QR est valide pour un seul usage, empêchant les attaques par rejeu.
• Chiffrement : Toutes les données dans le code QR sont chiffrées, garantissant que toute communication interceptée ne peut être déchiffrée par des parties non autorisées.

Le code QR scanné contient une URI spécifique avec le schéma FIDO, par exemple : FIDO:/07824133892604070278923969472008301099476228966286113051476699183587 6383562063181103169246410435938367110394959927031730060360967994421 343201235185697538107096654083332

Le scan du code QR déclenche le deuxième appareil de l'utilisateur (par exemple, un smartphone ou une tablette) pour interpréter l'URI FIDO et communiquer avec le serveur d'authentification, envoyant un signal que l'utilisateur tente de s'authentifier via un nouvel appareil (par exemple, l'ordinateur portable de l'ami). Cette action incite le serveur à générer un défi cryptographique, unique à cette tentative d'authentification.

Le défi est renvoyé au deuxième appareil de l'utilisateur (par exemple, un smartphone ou une tablette), où son passkey est stocké. L'appareil crée alors une signature numérique en utilisant la clé privée associée au passkey, sans que la clé privée ne quitte jamais l'appareil (par exemple, le smartphone ou la tablette). Le défi signé (signature) est ensuite renvoyé au serveur via un tunnel sécurisé et chiffré sur Internet, vérifiant l'intégrité et l'origine de la tentative d'authentification.

Le serveur valide la signature en utilisant la clé publique correspondante déjà associée au compte de l'utilisateur. Après une validation réussie, le serveur confirme l'authentification, permettant à l'utilisateur d'accéder au service sur le nouvel appareil.

Quelques aspects importants de confidentialité et de sécurité à considérer :

• Pas d'échange de données Bluetooth, purement Internet : Il est important de noter que dans cette authentification par passkey multiplateforme (transport hybride) basée sur un code QR, le Bluetooth n'est pas impliqué dans l'échange de données. Ce processus repose entièrement sur une connexion Internet pour la transmission de données chiffrées entre les appareils et le serveur. Cependant, le Bluetooth est utilisé pour une vérification de proximité des deux appareils.
• Les clés privées ne quittent pas l'appareil : Tout au long de ce processus, les clés privées de l'utilisateur restent en toute sécurité sur leur appareil.
• Aucune exposition de données sensibles : Aucune information sensible sur les passkeys ou les clés privées n'est transférée ou exposée pendant le processus d'authentification.
• Cryptographie asymétrique : Le mécanisme de défi-réponse garantit que ce qui est envoyé ne sont que des versions signées et non réutilisables de défis qui ne peuvent pas être exploitées pour un accès non autorisé.

En respectant ces protocoles techniques et de sécurité, la méthode du code QR pour l'authentification par passkey multiplateforme (transport hybride) maintient un haut niveau de sécurité tout en offrant un moyen pratique pour les utilisateurs d'authentifier leur identité sur de nouveaux appareils.

Outre le processus de scan du code QR, il y a aussi la vérification de proximité via Bluetooth (caBLE). S'assurer que le client et l'authentificateur sont physiquement proches l'un de l'autre est l'un des principaux avantages du protocole WebAuthn. Plus de détails sur le fonctionnement interne de ce processus sont décrits ci-dessous :

Le Bluetooth Low Energy (BLE) est une technologie de communication sans fil conçue pour l'échange de données à courte portée. Il joue un rôle central dans la confirmation de la proximité physique des appareils pendant le processus d'authentification.

Le caBLE est un protocole qui facilite le transfert sécurisé d'informations d'authentification entre les appareils utilisant le BLE. Lors de l'utilisation du caBLE pour l'authentification par passkey multiplateforme (transport hybride), l'appareil qui détient le passkey confirme la proximité de l'appareil demandeur via des signaux BLE. Une fois la proximité vérifiée, le processus d'authentification se poursuit, en exploitant le BLE pour une communication locale et sécurisée.

L'expérience utilisateur est améliorée car cette méthode nécessite généralement moins d'interaction directe de l'utilisateur ; les appareils à proximité physique se détectent automatiquement. Pour la sécurité, le caBLE offre un avantage significatif : il garantit que le processus d'authentification n'est effectué que lorsque les deux appareils sont proches l'un de l'autre, empêchant les attaquants distants d'initier le processus d'authentification.

Imaginez recevoir un code QR qui redirige vers un site malveillant. Si l'authentification est effectuée via ce code QR, il y a un risque que la session ou le cookie soit détourné. Le BLE contourne ce problème en ne s'appuyant pas sur un scan visuel, mais plutôt sur la présence physique des appareils. Cette vérification de proximité minimise le risque d'attaques de l'homme du milieu (man-in-the-middle), car la vérification de proximité ne se produit pas sur Internet ou via un support visuel.

Contrairement à d'autres méthodes, le caBLE n'échange pas réellement de données d'authentification comme les passkeys. Au lieu de cela, il utilise le BLE comme un canal de confirmation pour établir que les appareils sont physiquement proches. Cette vérification est conçue pour faire partie d'un processus d'authentification multifacteur où la proximité BLE est l'un des facteurs, garantissant que même si d'autres facteurs sont compromis, sans proximité physique, l'accès n'est pas accordé.

En intégrant le protocole caBLE, les développeurs peuvent offrir une méthode sécurisée et conviviale pour l'authentification par passkey multiplateforme (transport hybride) qui améliore la sécurité globale du processus d'authentification. La vérification de proximité ajoute une couche de protection supplémentaire qui est simple pour les utilisateurs et protège pourtant efficacement contre certains types de cyberattaques sophistiquées.

Les avantages suivants de cette méthode d'authentification par passkey multiplateforme (transport hybride) existent :

L'authentification par passkey multiplateforme via code QR et Bluetooth (transport hybride) est un moyen d'améliorer l'UX dans les scénarios multiplateformes par rapport à ne proposer aucune possibilité du tout. Cependant, le flux utilisateur est absolument nouveau pour la plupart des utilisateurs et nous ne nous attendons pas à ce que de nombreux utilisateurs non techniques comprennent ce qui se passe la première fois qu'ils rencontrent ce flux. La seule ressemblance avec l'introduction du flux de code QR peut être avec les flux de connexion pour, par exemple, WhatsApp Web ou Discord où des codes QR sont utilisés (bien que la fonctionnalité soit différente ici). Ainsi, le processus d'authentification par passkey multiplateforme analysé via code QR / Bluetooth (transport hybride) minimise l'effort de l'utilisateur dans le scénario multiplateforme, car il n'est pas nécessaire de saisir manuellement des informations d'identification, mais le flux global reste inconnu de la plupart des utilisateurs.

La sécurité de l'authentification par passkey multiplateforme (transport hybride) est renforcée par des techniques cryptographiques avancées. Lorsqu'un code QR est scanné ou qu'une connexion Bluetooth est établie pour l'authentification, les défis et réponses cryptographiques garantissent que seul l'appareil prévu peut terminer avec succès le processus d'authentification.

Les vérifications de proximité via Bluetooth ajoutent une couche de sécurité supplémentaire, confirmant que la tentative d'authentification est effectuée par quelqu'un ayant un accès physique à l'appareil secondaire.

Pendant le processus d'authentification multiplateforme (transport hybride), les passkeys ne sont jamais stockés temporairement sur des appareils ou des serveurs intermédiaires, ce qui prévient le risque que les passkeys soient interceptés ou divulgués pendant le processus de transfert. L'authentification se produit en temps réel, et le passkey reste lié à l'appareil principal de l'utilisateur, préservant son intégrité.

Les méthodes d'authentification par code QR et Bluetooth offrent intrinsèquement une protection contre le hameçonnage (phishing). Les utilisateurs sont moins susceptibles d'être trompés pour fournir un passkey à un site malveillant car le processus d'authentification nécessite des actions physiques spécifiques aux appareils de confiance de l'utilisateur.

Le processus de scan d'un code QR ou de connexion via Bluetooth se déroule généralement dans un environnement de confiance, réduisant les chances que les utilisateurs compromettent par inadvertance leurs informations d'identification.

Les inconvénients suivants de cette méthode d'authentification par passkey multiplateforme (transport hybride) existent :

L'introduction de toute nouvelle technologie peut entraîner une confusion chez les utilisateurs, surtout s'ils ne sont pas férus de technologie. L'authentification par passkey multiplateforme via code QR et Bluetooth (transport hybride) est un changement significatif par rapport aux méthodes d'authentification traditionnelles, et certains utilisateurs pourraient trouver le nouveau processus difficile à comprendre, ce qui pourrait entraîner un taux d'adoption plus lent. Cependant, nous nous attendons à ce que les utilisateurs s'y habituent avec le temps, donc le changement pourrait être plus difficile au début et deviendra plus fluide et mieux accepté au fil du temps.

Le succès de l'authentification par passkey multiplateforme (transport hybride) dépend fortement de la capacité de l'appareil de l'utilisateur à disposer des fonctionnalités nécessaires, telles qu'un appareil photo capable de scanner des codes QR et une fonctionnalité Bluetooth. Les utilisateurs avec des appareils plus anciens qui ne disposent pas de ces fonctionnalités ne pourront pas profiter de l'authentification par passkey multiplateforme (transport hybride), créant une fracture numérique basée sur les limitations matérielles.

Le comportement de l'utilisateur peut être imprévisible, et le fait de compter sur les utilisateurs pour effectuer des actions spécifiques comme scanner un code QR ou activer le Bluetooth peut introduire des erreurs de l'utilisateur. Par exemple, le Bluetooth peut parfois être considéré comme un défi pour l'UX en raison de problèmes d'appairage, de problèmes de découverte et d'une méfiance générale des utilisateurs envers les technologies sans fil pour les transactions sécurisées.

Les développeurs sont confrontés à la tâche de mettre à jour et de maintenir constamment les systèmes pour prendre en charge les dernières méthodes d'authentification. L'intégration de l'authentification par passkey multiplateforme (transport hybride) dans les systèmes existants exige que les développeurs se tiennent au courant des nouvelles normes, adoptent de nouvelles API et assurent la rétrocompatibilité, ce qui peut être gourmand en ressources et en temps.

Pour chaque nouvel appareil ou demande de connexion ultérieure, un nouveau passkey doit être créé si l'on n'utilise pas un compte cloud synchronisé comme le Trousseau iCloud ou un gestionnaire de mots de passe. Cela pourrait ajouter de la complexité à l'expérience utilisateur et peut créer de la frustration si les utilisateurs ne sont pas familiers avec le processus ou s'il n'est pas rendu intuitif.

Il existe un besoin inhérent d'éducation des utilisateurs lors de la mise en œuvre de nouvelles méthodes de sécurité comme l'authentification par passkey multiplateforme (transport hybride). S'assurer que les utilisateurs comprennent comment utiliser les codes QR et le Bluetooth en toute sécurité nécessite une communication claire et éventuellement un support client étendu.

Bien que l'authentification par passkey multiplateforme via code QR et Bluetooth (transport hybride) représente une avancée significative dans la technologie d'authentification, ces inconvénients potentiels soulignent la nécessité d'une conception conviviale, de systèmes de support robustes et d'une transition progressive et bien communiquée des méthodes traditionnelles aux méthodes innovantes. Comme pour tout changement technologique, l'équilibre entre les avantages de l'innovation et ses défis sera la clé d'une mise en œuvre réussie et d'une large acceptation par les utilisateurs.

Pour information : nous ignorons les clés de sécurité matérielles (par exemple, les YubiKeys) dans le test suivant et n'utilisons que des authentificateurs de plateforme intégrés aux appareils (par exemple, Face ID, Touch ID, Windows Hello). Dans le cas des clés de sécurité matérielles (par exemple, YubiKey), les valeurs pour transports seraient usb ou nfc par exemple.

Nous utilisons les combinaisons d'appareils / navigateurs suivantes et le Passkeys Debugger pour tester le comportement. Android n'est pas pris en compte car Android ne peut pas servir de client d'authentification multiplateforme (transport hybride) (voir le tableau ci-dessus) :

Pour tester le comportement, nous créons pour chaque combinaison un nouveau passkey avec les propriétés suivantes :

• userName : alex muller (aucune influence dans ce test)
• authenticatorAttachment : platform (car nous voulons exclure les clés de sécurité matérielles comme les YubiKeys)
• residentKey : preferred (aucune influence dans ce test)
• userVerification : preferred (aucune influence dans ce test)
• attestation : none (aucune influence dans ce test)
• hints : empty (voir explication ci-dessous)
• usePRF : no (aucune influence dans ce test)

Après la création réussie du passkey, nous modifions ensuite l'entrée de la propriété du serveur WebAuthn allowCredentials et lançons une demande de connexion. Nous voulons simuler un passkey supprimé sur l'appareil où nous avons créé le passkey, afin que l'appareil / navigateur recherche un autre appareil pouvant fournir un passkey via code QR / Bluetooth. Par conséquent, nous modifions l'ID d'identifiant (credential ID) et attribuons la valeur CHANGED-ID, afin qu'une correspondance échoue. De plus, nous modifions la propriété transports d'un identifiant WebAuthn dans allowCredentials et attribuons pour chaque combinaison appareil / navigateur les valeurs suivantes :

1. transports: [internal, hybrid] : Les passkeys peuvent être utilisés depuis l'authentificateur de plateforme (par exemple, Face ID, Touch ID, Windows Hello) ou via l'authentification multiplateforme
2. transports: [internal] : Les passkeys peuvent être utilisés depuis l'authentificateur de plateforme (par exemple, Face ID, Touch ID, Windows Hello)
3. Aucune propriété transports définie : comportement par défaut qui ne donne aucune restriction

Dans le site de test WebAuthn, il y a aussi la nouvelle fonctionnalité de WebAuthn Level 3 pour les hints des agents utilisateurs. Cette fonctionnalité peut améliorer l'expérience utilisateur si la partie de confiance (relying party) a certaines hypothèses sur la manière dont la demande de connexion peut être complétée de la manière la plus conviviale possible. Dans ce test, nous avons ignoré cette fonctionnalité car elle n'est pas encore déployée. Veuillez consulter les spécifications pour plus de détails.

Comme prévu, aucun passkey local ne correspond, il est donc suggéré de scanner le code QR et d'utiliser le passkey sur un autre appareil (car le système sait qu'il existe un passkey pour cet utilisateur).

De manière assez déroutante, le code QR est également affiché ici, même si nous n'autorisons que les identifiants internes. Nous n'avons pas pu trouver de raison valable à ce comportement.

Aucun passkey local ne correspond, il est donc suggéré de scanner le code QR ou d'utiliser une clé de sécurité matérielle (par exemple, YubiKey) / un authentificateur multiplateforme / un authentificateur itinérant.

Pour une raison quelconque, certaines parties de la modale apparaissent en allemand, qui est l'une des langues installées.

Comme prévu, toutes les formes d'authentification par passkey sont autorisées : via Windows Hello, via code QR, via des appareils connus et via des clés de sécurité matérielles.

Comme prévu, aucun passkey local ne correspond, il est donc suggéré de scanner le code QR et d'utiliser le passkey sur un autre appareil (car le système sait qu'il existe un passkey pour cet utilisateur).

De manière assez déroutante, le code QR est également affiché ici, même si nous n'autorisons que les identifiants internes. Nous n'avons pas pu trouver de raison valable à ce comportement.

Aucun passkey local ne correspond, il est donc suggéré de scanner le code QR ou d'utiliser une clé de sécurité matérielle (par exemple, YubiKey) / un authentificateur multiplateforme / un authentificateur itinérant.

Pour une raison quelconque, certaines parties de la modale apparaissent en allemand, qui est l'une des langues installées.

Comme prévu, toutes les formes d'authentification par passkey sont autorisées : via Windows Hello, via code QR, via des appareils connus et via des clés de sécurité matérielles.

Lors de la création du passkey, nous avons reçu l'erreur suivante (un passkey a tout de même été créé) :

error: TypeError: 'toJSON' called on an object that does not implement interface PublicKeyCredential.

Comme prévu, aucun passkey local ne correspond, il est donc suggéré de scanner le code QR et d'utiliser le passkey sur un autre appareil (car le système sait qu'il existe un passkey pour cet utilisateur).

De manière assez déroutante, le code QR est également affiché ici, même si nous n'autorisons que les identifiants internes. Nous n'avons pas pu trouver de raison valable à ce comportement.

Aucun passkey local ne correspond, il est donc suggéré de scanner le code QR ou d'utiliser une clé de sécurité matérielle (par exemple, YubiKey) / un authentificateur multiplateforme / un authentificateur itinérant.

Pour une raison quelconque, certaines parties de la modale apparaissent en allemand, qui est l'une des langues installées.

Comme prévu, toutes les formes d'authentification par passkey sont autorisées : via Windows Hello, via code QR, via des appareils connus et via des clés de sécurité matérielles.

Comme prévu, aucun passkey local ne correspond, il est donc suggéré de scanner le code QR et d'utiliser le passkey sur un autre appareil (car le système sait qu'il existe un passkey pour cet utilisateur). De plus, vous pouvez directement sélectionner l'un des appareils connus pour utiliser un passkey à partir de là.

La modale est assez différente de son homologue sur Windows dans Chrome 119.

C'est un comportement attendu, car nous n'autorisons que l'utilisation de passkeys internes mais ne trouvons aucun identifiant interne sur l'appareil (nous ne sommes pas autorisés à utiliser des passkeys hybrides). L'authentification par passkey échoue à cette étape et dans les implémentations réelles, vous devriez fournir une méthode d'authentification de secours.

Aucun passkey local ne correspond, il est donc suggéré de scanner le code QR ou d'utiliser une clé de sécurité matérielle (par exemple, YubiKey) / un authentificateur multiplateforme / un authentificateur itinérant. De plus, vous pouvez directement sélectionner l'un des appareils connus pour utiliser un passkey à partir de là.

La modale est assez différente de son homologue sur Windows dans Chrome 119.

Comme prévu, toutes les formes d'authentification par passkey sont autorisées : via Touch ID, via code QR, via des appareils connus et via des clés de sécurité matérielles.

Comme prévu, aucun passkey local ne correspond, il est donc suggéré de scanner le code QR et d'utiliser le passkey sur un autre appareil (car le système sait qu'il existe un passkey pour cet utilisateur).

De manière assez déroutante, le code QR est également affiché ici, même si nous n'autorisons que les identifiants internes. Nous n'avons pas pu trouver de raison valable à ce comportement.

Aucun passkey local ne correspond, il est donc suggéré de scanner le code QR ou d'utiliser une clé de sécurité matérielle (par exemple, YubiKey) / un authentificateur multiplateforme / un authentificateur itinérant.

Comme prévu, la plupart des formes d'authentification par passkey sont autorisées : via Touch ID, via code QR et via des clés de sécurité matérielles. Pour une raison quelconque, les appareils connus ne sont pas affichés.

Comme prévu, aucun passkey local ne correspond, il est donc suggéré de scanner le code QR et d'utiliser le passkey sur un autre appareil (car le système sait qu'il existe un passkey pour cet utilisateur).

De manière assez déroutante, le code QR est également affiché ici, même si nous n'autorisons que les identifiants internes. Nous n'avons pas pu trouver de raison valable à ce comportement.

Aucun passkey local ne correspond, il est donc suggéré de scanner le code QR ou d'utiliser une clé de sécurité matérielle (par exemple, YubiKey) / un authentificateur multiplateforme / un authentificateur itinérant.

Comme prévu, la plupart des formes d'authentification par passkey sont autorisées : via Face ID, via code QR et via des clés de sécurité matérielles. Pour une raison quelconque, les appareils connus ne sont pas affichés.

Comme prévu, aucun passkey local ne correspond, il est donc suggéré de scanner le code QR et d'utiliser le passkey sur un autre appareil (car le système sait qu'il existe un passkey pour cet utilisateur).

De manière assez déroutante, le code QR est également affiché ici, même si nous n'autorisons que les identifiants internes. Nous n'avons pas pu trouver de raison valable à ce comportement.

Aucun passkey local ne correspond, il est donc suggéré de scanner le code QR ou d'utiliser une clé de sécurité matérielle (par exemple, YubiKey) / un authentificateur multiplateforme / un authentificateur itinérant.

Comme prévu, la plupart des formes d'authentification par passkey sont autorisées : via Face ID, via code QR et via des clés de sécurité matérielles. Pour une raison quelconque, les appareils connus ne sont pas affichés.

Ci-dessous, pour les appareils Windows 10, nous avons décidé d'aller plus loin et d'analyser le comportement lorsque le Bluetooth est désactivé ou non disponible sur une machine Windows 10 en général. En particulier pour les anciens ordinateurs de bureau, c'est encore un scénario très courant car ces appareils n'ont souvent pas de module Bluetooth, rendant l'authentification multiplateforme via code QR et Bluetooth impossible.

8.8.1.1 transports: [internal, hybrid]

Comme prévu, aucun passkey local ne correspond, il est donc suggéré d'utiliser le passkey sur un autre appareil (car le système sait qu'il existe un passkey pour cet utilisateur - première capture d'écran) ou de choisir de scanner le code QR (deuxième capture d'écran).

8.8.1.2 transports: [internal]

De manière assez déroutante, vous êtes invité à entrer votre code PIN Windows Hello (ou votre empreinte digitale / scan facial si configuré sur l'appareil), même si nous avons changé l'ID d'identifiant (il ne devrait donc pas trouver l'identifiant car il n'est pas spécifié dans la propriété allowCredentials). Cependant, après avoir soumis le code PIN Windows Hello, une erreur est levée : "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Du point de vue de l'utilisateur, c'est un comportement plutôt déroutant mais logique car il pourrait fournir des informations sur les passkeys de l'utilisateur sans son consentement.

8.8.1.3 Aucune propriété transports définie

Aucun passkey local ne correspond, il est donc suggéré de scanner le code QR ou d'utiliser une clé de sécurité matérielle (par exemple, YubiKey) / un authentificateur multiplateforme / un authentificateur itinérant.

8.8.1.4 allowCredentials vide

Comme prévu, toutes les formes d'authentification par passkey sont autorisées : via Windows Hello, via code QR, via des appareils connus et via des clés de sécurité matérielles.

8.8.2.1 transports: [internal, hybrid]

C'est un message vraiment déroutant pour les utilisateurs, car il n'est pas explicitement indiqué ce qu'ils doivent faire et comment ils peuvent s'authentifier. La seule option qu'ils ont est de cliquer sur "Annuler", ce qui rend ce scénario une impasse.

8.8.2.2 transports: [internal]

Ce comportement est le même que lorsque le Bluetooth est activé. Il est très déroutant que l'utilisateur soit invité à entrer le code PIN Windows Hello (ou son empreinte digitale / scan facial si configuré sur l'appareil), même si nous avons changé l'ID d'identifiant (il ne devrait donc pas trouver l'identifiant car il n'est pas spécifié dans la propriété allowCredentials). Cependant, après avoir soumis le code PIN Windows Hello, une erreur est levée : "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Du point de vue de l'utilisateur, c'est un comportement plutôt déroutant mais logique car il pourrait fournir des informations sur les passkeys de l'utilisateur sans son consentement.

8.8.2.3 Aucune propriété transports définie

Aucun passkey local ne correspond, la seule option que vous avez est d'utiliser une clé de sécurité matérielle (par exemple, YubiKey) / un authentificateur multiplateforme / un authentificateur itinérant.

8.8.2.4 allowCredentials vide

L'authentification par passkey n'est possible que via Windows Hello et les clés de sécurité matérielles.

8.9.1.1 transports: [internal, hybrid]

Comme prévu, aucun passkey local ne correspond, il est donc suggéré de scanner le code QR et d'utiliser le passkey sur un autre appareil (car le système sait qu'il existe un passkey pour cet utilisateur).

8.9.1.2 transports: [internal]

De manière assez déroutante, vous êtes invité à entrer votre code PIN Windows Hello (ou votre empreinte digitale / scan facial si configuré sur l'appareil), même si nous avons changé l'ID d'identifiant (il ne devrait donc pas trouver l'identifiant car il n'est pas spécifié dans la propriété allowCredentials). Cependant, après avoir soumis le code PIN Windows Hello, une erreur est levée : "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Du point de vue de l'utilisateur, c'est un comportement plutôt déroutant mais logique car il pourrait fournir des informations sur les passkeys de l'utilisateur sans son consentement.

8.9.1.3 Aucune propriété transports définie

Aucun passkey local ne correspond, il est donc suggéré de scanner le code QR ou d'utiliser une clé de sécurité matérielle (par exemple, YubiKey) / un authentificateur multiplateforme / un authentificateur itinérant.

8.9.1.4 allowCredentials vide

Comme prévu, toutes les formes d'authentification par passkey sont autorisées : via Windows Hello, via code QR et via des clés de sécurité matérielles. Pour une raison quelconque, les appareils connus ne sont pas affichés.

8.9.2.1 transports: [internal, hybrid]

C'est un message vraiment déroutant pour les utilisateurs, car il n'est pas explicitement indiqué ce qu'ils doivent faire et comment ils peuvent s'authentifier. La seule option qu'ils ont est de cliquer sur "Annuler", ce qui rend ce scénario une impasse.

8.9.2.2 transports: [internal]

Ce comportement est le même que lorsque le Bluetooth est activé. Il est très déroutant que l'utilisateur soit invité à entrer le code PIN Windows Hello (ou son empreinte digitale / scan facial si configuré sur l'appareil), même si nous avons changé l'ID d'identifiant (il ne devrait donc pas trouver l'identifiant car il n'est pas spécifié dans la propriété allowCredentials). Cependant, après avoir soumis le code PIN Windows Hello, une erreur est levée : "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Du point de vue de l'utilisateur, c'est un comportement plutôt déroutant mais logique car il pourrait fournir des informations sur les passkeys de l'utilisateur sans son consentement.

8.9.2.3 Aucune propriété transports définie

Aucun passkey local ne correspond, la seule option que vous avez est d'utiliser une clé de sécurité matérielle (par exemple, YubiKey) / un authentificateur multiplateforme / un authentificateur itinérant.

8.9.2.4 allowCredentials vide

L'authentification par passkey n'est possible que via Windows Hello et les clés de sécurité matérielles.

8.10.1.1 transports: [internal, hybrid]

Comme prévu, aucun passkey local ne correspond, il est donc suggéré de scanner le code QR et d'utiliser le passkey sur un autre appareil (car le système sait qu'il existe un passkey pour cet utilisateur).

8.10.1.2 transports: [internal]

De manière assez déroutante, vous êtes invité à entrer votre code PIN Windows Hello (ou votre empreinte digitale / scan facial si configuré sur l'appareil), même si nous avons changé l'ID d'identifiant (il ne devrait donc pas trouver l'identifiant car il n'est pas spécifié dans la propriété allowCredentials). Cependant, après avoir soumis le code PIN Windows Hello, une erreur est levée : "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Du point de vue de l'utilisateur, c'est un comportement plutôt déroutant mais logique car il pourrait fournir des informations sur les passkeys de l'utilisateur sans son consentement.

8.10.1.3 Aucune propriété transports définie

Aucun passkey local ne correspond, il est donc suggéré de scanner le code QR ou d'utiliser une clé de sécurité matérielle (par exemple, YubiKey) / un authentificateur multiplateforme / un authentificateur itinérant.

8.10.1.4 allowCredentials vide

Comme prévu, toutes les formes d'authentification par passkey sont autorisées : via Windows Hello, via code QR et via des clés de sécurité matérielles. Pour une raison quelconque, les appareils connus ne sont pas affichés.

8.10.2.1 transports: [internal, hybrid]

C'est un message vraiment déroutant pour les utilisateurs, car il n'est pas explicitement indiqué ce qu'ils doivent faire et comment ils peuvent s'authentifier. La seule option qu'ils ont est de cliquer sur "Annuler", ce qui rend ce scénario une impasse. Pour une raison quelconque, certaines parties de la modale de sécurité Windows sont également affichées en allemand (une deuxième langue installée sur cet appareil).

8.10.2.2 transports: [internal]

Ce comportement est le même que lorsque le Bluetooth est activé. Il est très déroutant que l'utilisateur soit invité à entrer le code PIN Windows Hello (ou son empreinte digitale / scan facial si configuré sur l'appareil), même si nous avons changé l'ID d'identifiant (il ne devrait donc pas trouver l'identifiant car il n'est pas spécifié dans la propriété allowCredentials). Cependant, après avoir soumis le code PIN Windows Hello, une erreur est levée : "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Du point de vue de l'utilisateur, c'est un comportement plutôt déroutant mais logique car il pourrait fournir des informations sur les passkeys de l'utilisateur sans son consentement.

8.10.2.3 Aucune propriété transports définie

Aucun passkey local ne correspond, la seule option que vous avez est d'utiliser une clé de sécurité matérielle (par exemple, YubiKey) / un authentificateur multiplateforme / un authentificateur itinérant.

8.10.2.4 allowCredentials vide

L'authentification par passkey n'est possible que via Windows Hello et les clés de sécurité matérielles.

8.11.1.1 transports: [internal, hybrid]

Comme prévu, aucun passkey local ne correspond, il est donc suggéré de scanner le code QR et d'utiliser le passkey sur un autre appareil (car le système sait qu'il existe un passkey pour cet utilisateur).

8.11.1.2 transports: [internal]

De manière assez déroutante, vous êtes invité à entrer votre code PIN Windows Hello (ou votre empreinte digitale / scan facial si configuré sur l'appareil), même si nous avons changé l'ID d'identifiant (il ne devrait donc pas trouver l'identifiant car il n'est pas spécifié dans la propriété allowCredentials). Cependant, après avoir soumis le code PIN Windows Hello, une erreur est levée : "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Du point de vue de l'utilisateur, c'est un comportement plutôt déroutant mais logique car il pourrait fournir des informations sur les passkeys de l'utilisateur sans son consentement.

8.11.1.3 Aucune propriété transports définie

Aucun passkey local ne correspond, il est donc suggéré de scanner le code QR ou d'utiliser une clé de sécurité matérielle (par exemple, YubiKey) / un authentificateur multiplateforme / un authentificateur itinérant.

8.11.1.4 allowCredentials vide

Comme prévu, toutes les formes d'authentification par passkey sont autorisées : via Windows Hello, via code QR et via des clés de sécurité matérielles. Pour une raison quelconque, les appareils connus ne sont pas affichés.

8.11.2.1 transports: [internal, hybrid]

C'est un message vraiment déroutant pour les utilisateurs, car il n'est pas explicitement indiqué ce qu'ils doivent faire et comment ils peuvent s'authentifier. La seule option qu'ils ont est de cliquer sur "Annuler", ce qui rend ce scénario une impasse.

8.11.2.2 transports: [internal]

Ce comportement est le même que lorsque le Bluetooth est activé. Il est très déroutant que l'utilisateur soit invité à entrer le code PIN Windows Hello (ou son empreinte digitale / scan facial si configuré sur l'appareil), même si nous avons changé l'ID d'identifiant (il ne devrait donc pas trouver l'identifiant car il n'est pas spécifié dans la propriété allowCredentials). Cependant, après avoir soumis le code PIN Windows Hello, une erreur est levée : "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Du point de vue de l'utilisateur, c'est un comportement plutôt déroutant mais logique car il pourrait fournir des informations sur les passkeys de l'utilisateur sans son consentement.

8.11.2.3 Aucune propriété transports définie

Aucun passkey local ne correspond, la seule option que vous avez est d'utiliser une clé de sécurité matérielle (par exemple, YubiKey) / un authentificateur multiplateforme / un authentificateur itinérant.

8.11.2.4 allowCredentials vide

L'authentification par passkey n'est possible que via Windows Hello et les clés de sécurité matérielles.

• Utilisez des bibliothèques et des frameworks qui abstraient certaines des complexités de l'API WebAuthn pure.
• Envisagez les scénarios d'authentification multiplateforme dès le début pour vous assurer qu'une large base d'utilisateurs puisse bénéficier de votre implémentation de passkeys. Selon vos choix de conception, vous pouvez également proposer des méthodes de connexion alternatives dans ces scénarios.
• Développez des mécanismes de repli pour les scénarios où l'authentification par passkey multiplateforme (transport hybride) pourrait ne pas être possible en raison des limitations de l'appareil.
• La plus grande décision de conception est de décider si vous voulez promouvoir l'authentification par passkey multiplateforme via code QR / Bluetooth (transport hybride) et en faire une méthode proéminente pour l'authentification par passkey ou utiliser des hints pour ne pas la promouvoir activement. Dans ce dernier cas, on essaie toujours d'utiliser immédiatement les passkeys stockés en interne et seulement si aucun passkey interne n'est trouvé, un code QR pour l'authentification multiplateforme (transport hybride) est affiché. Cela doit être défini dans les options de votre serveur WebAuthn dans les propriétés excludeCredentials et allowCredentials. Dans la propriété excludeCredentials de votre serveur WebAuthn, vous pouvez voir les informations de transport sur les identifiants déjà créés. Dans la propriété allowCredentials, vous pouvez spécifier le comportement dans le processus de connexion (voir les tests ci-dessus).
• De plus, vous ne pouvez pas empêcher entièrement l'authentification par passkey multiplateforme (transport hybride) (voir les tests ci-dessus avec transports: [internal]), vous devez donc être préparé à ce que vos utilisateurs trouvent cette méthode et aient des questions. L'apparition de cette authentification multiplateforme (transport hybride) se produira en particulier si les utilisateurs commencent à supprimer des passkeys localement.

• Créez des guides et des tutoriels complets qui guident les utilisateurs à travers le processus d'authentification par passkey multiplateforme (transport hybride).
• Utilisez des infobulles dans l'application et des sections d'aide contextuelle pour guider les utilisateurs lors de leur première expérience d'authentification par passkey multiplateforme (transport hybride).
• Fournissez des sections FAQ et de dépannage sur votre site web ou dans l'application.

• Mettez en œuvre des sessions à durée limitée pour les connexions par passkey via code QR ou Bluetooth afin de garantir que l'accès n'est que temporaire et sécurisé.
• Assurez-vous que l'authentification par passkey multiplateforme (transport hybride) ne compromet aucun protocole de sécurité existant, en maintenant l'intégrité des données utilisateur.
• Considérez les implications en matière de confidentialité et assurez-vous que tout accès temporaire accordé via l'authentification par passkey multiplateforme (transport hybride) est enregistré et surveillé conformément aux meilleures pratiques de sécurité.

L'authentification par passkey multiplateforme via code QR / Bluetooth (transport hybride) offre un équilibre entre sécurité et UX. Cependant, c'est un processus entièrement nouveau pour la plupart des utilisateurs et pourrait causer de nombreuses situations déroutantes, vous devez donc réfléchir attentivement si vous voulez le promouvoir.

Nous espérons avoir pu éclaircir le sujet de l'authentification par passkey multiplateforme (transport hybride) via code QR / Bluetooth, expliquer comment configurer les choses et à quoi ressemble le comportement sur différentes combinaisons d'appareils / navigateurs. Si vous avez des questions, n'hésitez pas à nous contacter via notre communauté sur les passkeys ou à vous abonner à notre Substack sur les passkeys. Rendons Internet plus sûr en propageant les passkeys.