Les passkeys identifient-elles les utilisateurs ? Risques WebAuthn

Les passkeys utilisent WebAuthn pour créer et utiliser des identifiants à clé publique. Un navigateur peut aussi exposer des informations limitées sur la disponibilité de certains flux WebAuthn. Ces résultats peuvent aider une partie de confiance à choisir l’option de connexion à présenter. Ce sont des indices de fonctionnalités, pas un inventaire du matériel, une preuve d’identité, une preuve qu’un identifiant existe ni une garantie qu’une connexion ultérieure réussira. BotBrowser peut garder les résultats de capacité WebAuthn cohérents avec un profil dans un contexte contrôlé ; il ne peut pas transformer ces résultats en preuve d’un appareil ou d’un identifiant.

Cette distinction compte pour la confidentialité et la conception du produit. Un résultat de capacité peut varier selon la prise en charge du navigateur, la politique du système d’exploitation, l’état du compte, les authentificateurs disponibles et le contexte actuel. Le traiter comme une affirmation définitive sur un appareil transforme une donnée de compatibilité en inférence infondée. Le traiter comme un résultat d’identifiant peut créer une expérience de connexion déroutante.

La spécification WebAuthn Level 3 définit les interfaces du navigateur et les cérémonies d’identifiants pertinentes. La référence PublicKeyCredential de MDN fournit la documentation destinée au navigateur. Ensemble, elles justifient un modèle prudent : disponibilité d’une capacité, vérification de l’utilisateur, utilisation de l’authentificateur, création et récupération d’un identifiant sont des événements liés, mais distincts.

Résumé

• isUserVerifyingPlatformAuthenticatorAvailable() renvoie un booléen indiquant si un authentificateur de plateforme vérifiant l'utilisateur peut être découvert maintenant, sans nommer d'authentificateur, de capteur, de compte ni d'identifiant.
• isConditionalMediationAvailable() indique seulement si la médiation conditionnelle est disponible, pas le résultat d'une connexion : une méthode absente ou une valeur false exige donc une autre voie visible.
• Le contexte sécurisé, l'origine et l'identifiant RP encadrent chaque cérémonie : navigator.credentials.create() et navigator.credentials.get() ne produisent un résultat vérifiable par le serveur que pour l'identifiant RP qui a signé le défi.
• Une invite annulée, un défi expiré, un identifiant RP qui ne correspond pas et un authentificateur indisponible sont quatre issues distinctes, et aucune ne relève d'un attribut de compte durable.
• BotBrowser peut rejouer une configuration documentée des capacités du client pour vérifier que la page de connexion garde son repli, mais il ne crée pas de matériel d'authentification, n'inscrit aucun identifiant et ne vérifie aucune assertion.

Sommaire

• Voir la vidéo
• Carte sources-affirmations
• Ce que peut signifier un résultat de capacité
• Limites de l'origine et de la partie de confiance
• Limites de confidentialité des indices WebAuthn
• Concevoir un parcours de connexion respectueux
• Conclusion pratique

Voir la vidéo

Cette vidéo en anglais vérifie quelles réponses une page peut lire avec les appels de capacité WebAuthn, d’abord sur une page de laboratoire locale avec trois ensembles de capacités déclarés, puis sur deux versions réelles de Chrome sous Windows et Ubuntu. Aucun identifiant n’est créé et la vérification n’établit ni identité, ni anonymat, ni accès, ni la décision d’un site distant. La piste audio est en anglais.

Carte sources-affirmations

• Contexte sécurisé et PublicKeyCredential (référence normative/API) : la référence PublicKeyCredential de MDN documente l’exigence d’un contexte sécurisé. Recommandation de l’article : traiter ce prérequis comme un contrôle de compatibilité, jamais comme la preuve qu’un authentificateur ou un identifiant existe.
• Disponibilité de l’authentificateur de plateforme (référence normative/API) : W3C 5.1.6 et la référence de la méthode MDN définissent un contrôle de disponibilité, pas l’existence d’un identifiant. Recommandation de l’article : utiliser le booléen uniquement pour choisir de proposer une voie avec authentificateur de plateforme.
• Médiation conditionnelle (référence normative/API) : les capacités du client W3C et la référence MDN de la médiation conditionnelle décrivent un indicateur de disponibilité, pas un résultat de connexion. Recommandation de l’article : conserver une autre voie si la méthode manque ou est indisponible.
• Origine, RP ID et cérémonie (règles normatives du protocole) : les règles W3C d’origine et de RP ID limitent les identifiants à la partie de confiance, tandis que les algorithmes de cérémonie exigent une requête, la participation de l’utilisateur et une réponse vérifiée. Recommandation de l’article : décider du compte, de l’autorisation et de la récupération seulement après vérification serveur ; ne pas les déduire d’un signal de capacité.

Ce que peut signifier un résultat de capacité

L’interface PublicKeyCredential n’est disponible que dans des contextes sécurisés. Le transport sécurisé est donc nécessaire pour utiliser WebAuthn, mais il ne prouve pas qu’un authentificateur ou un identifiant est disponible. Une page peut ne pas avoir accès à WebAuthn parce que le contexte n’est pas sécurisé, parce que le navigateur ne prend pas en charge l’interface concernée ou parce qu’une méthode facultative précise est absente. Chaque cas appelle une expérience différente.

La section 5.1.6 de WebAuthn Level 3 définit isUserVerifyingPlatformAuthenticatorAvailable(). La spécification indique que les parties de confiance l’utilisent pour déterminer si elles peuvent créer un nouvel identifiant avec un authentificateur de plateforme vérifiant l’utilisateur. Le résultat est un booléen issu d’une procédure de la plateforme cliente qui détecte les authentificateurs de plateforme disponibles et capables de vérifier l’utilisateur. Un résultat vrai aide à décider s’il faut proposer une voie d’inscription avec un authentificateur de plateforme. Il ne nomme pas l’authentificateur, ne révèle pas un capteur précis, n’établit pas l’inscription d’une personne et ne confirme pas qu’un identifiant est déjà enregistré sur le site.

Le mot plateforme est important. Dans WebAuthn, le rattachement d’un authentificateur et sa capacité à vérifier l’utilisateur sont des notions du protocole. Elles n’autorisent pas un site à transformer une réponse booléenne en affirmation sur la biométrie ou le matériel d’une personne. Un appareil peut proposer plusieurs authentificateurs et l’utilisateur peut en choisir un autre pendant une cérémonie. Les réglages, la politique de l’entreprise, la configuration du compte ou des changements apportés à un authentificateur peuvent modifier ce qui est utilisable au début de la cérémonie.

La section 5.1.7 de la spécification Level 3 décrit les capacités du client comme un ensemble limité de clés servant à proposer certains flux et certaines expériences. Ce but est plus restreint que l’identité ou la classification d’un appareil. Par exemple, un résultat peut indiquer si l’écran de connexion propose un parcours particulier à côté d’un champ de nom d’utilisateur. Il ne doit pas servir à étiqueter un visiteur, à déduire la présence d’un identifiant ou à décider qu’une récupération de mot de passe est inutile.

La médiation conditionnelle demande la même prudence. La spécification décrit isConditionalMediationAvailable() comme un indicateur de disponibilité de la médiation conditionnelle. Il peut aider une application à choisir une interface, mais n’effectue pas de connexion et ne montre pas qu’une passkey est disponible pour la partie de confiance actuelle. MDN le répertorie comme méthode statique de PublicKeyCredential et précise que l’API est limitée aux contextes sécurisés dans les navigateurs compatibles. L’application doit gérer une méthode absente ou un résultat indisponible en conservant une autre voie de connexion.

Disponibilité, vérification de l'utilisateur et identifiants

La disponibilité est la première couche. Elle demande si le navigateur peut exposer une option WebAuthn donnée dans l’environnement actuel. Elle n’affirme pas qu’un utilisateur peut s’authentifier. La vérification de l’utilisateur est une autre couche : c’est une propriété demandée et évaluée durant une cérémonie d’identifiant, au cours de laquelle l’authentificateur peut devoir vérifier l’utilisateur selon la requête et sa propre politique. Un résultat de capacité ne réalise pas cette vérification.

La disponibilité de l’authentificateur est également distincte de celle de l’identifiant. Un authentificateur de plateforme peut être disponible alors qu’aucun identifiant n’a été créé pour un site donné. À l’inverse, un utilisateur peut posséder un identifiant valide utilisable avec un autre authentificateur que celui attendu par l’application. Pour savoir de manière fiable si une connexion peut aboutir, il faut exécuter la requête WebAuthn normale après le choix de l’utilisateur et après que l’application a fourni les données correctes de la partie de confiance.

La création d’un identifiant et la production d’une assertion sont des opérations actives. Lors de l’inscription, le navigateur et l’authentificateur peuvent créer un nouvel identifiant à clé publique après la demande de la partie de confiance. Lors de l’authentification, ils peuvent produire une assertion pour un identifiant existant. Ces opérations peuvent réussir, être refusées ou annulées par l’utilisateur, être indisponibles ou échouer pour d’autres raisons propres à la requête. Une vérification de capacité ne peut remplacer aucune de ces opérations.

La description de l’interface PublicKeyCredential dans la spécification Level 3 rend cette séparation visible. Un identifiant renvoyé contient une réponse après la création d’un nouvel identifiant ou la demande d’une assertion. À l’inverse, une méthode de capacité renvoie des informations servant à orienter un flux possible. Les applications doivent représenter ces éléments comme des états distincts dans leur interface et leur télémétrie. « Peut proposer cette option » n’est pas le même état que « l’utilisateur l’a approuvée », « un identifiant a été créé » ou « une assertion a été vérifiée ».

L’annulation doit être traitée explicitement. Une personne peut fermer ou refuser l’invite de l’authentificateur. Ce résultat ne prouve ni son identité, ni son matériel, ni sa volonté d’utiliser des passkeys dans tous les contextes : c’est un résultat d’interaction. Présentez un retour clair vers le mot de passe, la récupération ou une autre méthode prise en charge, et n’essayez pas de relancer une cérémonie sans nouvelle action de l’utilisateur. Une interface attentive explique le choix avant d’ouvrir le flux d’authentification et donne ensuite une sortie claire.

Le même principe vaut pour les erreurs. Un authentificateur indisponible, un défi serveur expiré, une incompatibilité d’RP, un compte modifié et une politique du navigateur peuvent produire des résultats différents. Les équipes produit ne devraient enregistrer que les détails de diagnostic nécessaires pour aider l’utilisateur et éviter de transformer une catégorie d’échec en profil persistant. L’aperçu de l’empreinte liée aux permissions du navigateur fournit un contexte complémentaire pour traiter les états exposés par le navigateur comme des signaux limités et non comme des faits d’identité.

Limites de l’origine et de la partie de confiance

WebAuthn a volontairement un périmètre défini. La spécification Level 3 indique que les opérations sont liées à une origine précise et que l’origine complète du demandeur est incluse et signée dans les objets d’attestation et les assertions. Elle précise aussi que chaque identifiant est lié à un identifiant de partie de confiance, ou RP ID. Un authentificateur limite les identifiants créés pour un RP ID aux opérations demandées par ce RP ID.

Ces limites expliquent pourquoi un résultat de capacité ne peut pas établir un accès à des identifiants entre sites. Un site ne reçoit une assertion que lors d’une cérémonie pour sa propre origine et son RP ID, sous réserve de la validation du navigateur et du traitement de l’authentificateur. Il ne peut pas utiliser un indice général de capacité à la place des contrôles d’origine et de partie de confiance du protocole. L’exigence de contexte sécurisé fait partie du même modèle de sécurité.

Pour une application, la règle pratique est simple. Lancez une cérémonie d’inscription ou de connexion uniquement pour l’origine et le RP ID prévus du site. Laissez le navigateur et l’authentificateur appliquer leurs rôles. Vérifiez la réponse côté serveur conformément au protocole WebAuthn avant de considérer la connexion terminée. Ne fondez pas la découverte de comptes, l’autorisation ou la récupération sur une réponse de capacité du client.

Les origines associées exigent une configuration explicite, pas des suppositions. La spécification contient des règles pour utiliser WebAuthn entre origines associées. Un nom d’organisation commun ou un nom d’hôte similaire ne suffit pas à créer une relation d’identifiants. Les équipes qui exploitent plusieurs sites doivent définir leur RP ID et leur politique d’origine avant de lancer un flux de passkeys, le tester sur leurs domaines pris en charge et documenter le comportement de repli lorsque cette relation ne s’applique pas.

La limite d’origine améliore aussi la confidentialité. Elle restreint la capacité d’une partie de confiance à utiliser des identifiants WebAuthn délivrés pour une autre partie de confiance. Cette protection ne signifie pas que les choix de collecte du site respectent automatiquement la vie privée. Un site doit tout de même réduire ce qu’il journalise, expliquer pourquoi il propose une option d’authentification et éviter d’utiliser les informations de compatibilité pour un profilage sans rapport.

Limites de confidentialité des indices WebAuthn

Les informations de capacité peuvent s’ajouter à un ensemble plus large de données exposées par le navigateur. Un résultat peut être utile avec d’autres informations pour décider de la compatibilité et changer lorsque le logiciel, la politique ou l’état du compte évolue. Il n’est donc ni un identifiant stable ni une description fiable d’un appareil physique. Il ne peut pas prouver qu’un visiteur possède un appareil précis, dispose d’une méthode biométrique particulière ou détient un compte auprès d’une partie de confiance.

Cette limite est particulièrement importante lorsqu’une application décide quoi conserver. Un booléen ou un petit enregistrement de capacités peut suffire pour choisir entre les options de connexion visibles pendant la visite. Il n’a pas à devenir un attribut de compte, une dimension analytique ou un identifiant de longue durée. Le conserver pour ces buts sans rapport augmente le risque qu’une condition de compatibilité temporaire soit mal comprise plus tard. Si la journalisation diagnostique est nécessaire, définissez une courte durée de conservation, limitez l’accès et documentez la raison opérationnelle de la collecte.

Les sites doivent aussi distinguer les informations fournies volontairement par l’utilisateur de celles déduites de la prise en charge du navigateur. Un identifiant de compte saisi dans un formulaire, le choix explicite d’une méthode de connexion et une cérémonie d’identifiant terminée ont des significations et des attentes de confidentialité différentes. Un indice de fonctionnalité n’appartient à aucune de ces catégories. Afficher une option de passkey ne constitue pas un consentement à démarrer une cérémonie, et refuser une invite ne constitue pas un consentement à enregistrer une préférence sur la personne.

L’accessibilité et la récupération reposent sur la même distinction. Certaines personnes utilisent des authentificateurs externes, des appareils partagés, des technologies d’assistance ou des parcours de récupération qui ne ressemblent pas à un flux typique d’authentificateur de plateforme. Un résultat de capacité ne doit pas supprimer les parcours dont elles ont besoin. Gardez les libellés centrés sur l’action proposée, évitez les suppositions sur l’appareil de l’utilisateur et permettez de quitter le flux sans perdre la progression. Ces choix rendent l’écran de connexion plus utile même lorsque WebAuthn est entièrement pris en charge.

Les équipes d’assistance bénéficient elles aussi d’un langage précis. Un rapport peut indiquer qu’une option de passkey a été proposée, qu’une personne l’a annulée ou que le serveur n’a pas vérifié une assertion. Il ne doit pas affirmer qu’une personne n’a pas de matériel biométrique ni qu’un navigateur correspond définitivement à un environnement donné sur la base d’un seul résultat. Des descriptions limitées préservent un contexte de dépannage utile sans transformer un état du protocole en affirmation d’identité.

La navigation privée mérite également un langage nuancé. Les navigateurs peuvent appliquer des comportements différents pour le stockage, les comptes, les permissions et les identifiants dans les contextes privés. La spécification WebAuthn ne dit pas que chaque fenêtre privée doit renvoyer les mêmes valeurs de capacité ou terminer les mêmes cérémonies qu’une fenêtre normale. Les applications doivent tester les navigateurs et les modes qu’elles prennent en charge et conserver une solution de repli lorsque WebAuthn est indisponible. Il ne faut pas dire aux utilisateurs que la navigation privée rend une réponse WebAuthn identique, anonyme ou prévisible.

Le mode d’affichage ne justifie pas non plus une conclusion universelle. Un environnement avec interface ou sans interface peut varier selon la version du navigateur, le système d’exploitation, la politique, les authentificateurs disponibles et la configuration de test. La norme définit la sémantique WebAuthn, pas une égalité garantie entre les modes d’affichage. Les équipes qui ont besoin d’une compatibilité entre environnements doivent tester leur propre matrice prise en charge et rapporter précisément le support observé. Elles ne doivent pas utiliser un seul résultat pour caractériser tous les navigateurs sans interface ou de bureau.

Supprimer une interface, remplacer une méthode du navigateur ou tenter de forcer un résultat n’est pas un contrôle de confidentialité fiable. Cela peut rendre inexacte la décision de compatibilité d’une application ou interrompre un flux d’authentification. Plus important encore, un parcours de compte public ne doit pas promettre qu’une configuration sera invisible pour un site ou à l’abri d’inférences supplémentaires. Les affirmations de confidentialité doivent rester dans les limites de ce que l’utilisateur peut observer et de ce que la documentation du produit peut étayer.

Pour les utilisateurs, les questions utiles sont concrètes : le site explique-t-il le rôle de l’option passkey ? L’utilisateur peut-il choisir une autre méthode de connexion ? Le site ne demande-t-il un identifiant qu’après le choix de ce parcours ? Le site ne conserve-t-il que les informations nécessaires au fonctionnement sécurisé du compte ? Ces questions sont plus utiles que de vouloir déduire une identité ou une certitude matérielle d’un indice de fonctionnalité.

Le guide sur les propriétés de navigator et l’empreinte présente le principe général. Les valeurs individuelles du navigateur peuvent servir d’entrées de compatibilité, mais leur sens dépend du contexte. Les décisions de confidentialité doivent privilégier la minimisation des données, des choix compréhensibles et le test du comportement pris en charge, plutôt que de traiter une réponse d’API comme un profil concluant.

Concevoir un parcours de connexion respectueux

Proposez les passkeys comme un choix explicite de connexion ou d’inscription. Un indice de capacité peut aider à déterminer si une option doit être mise en avant, mais l’utilisateur doit décider de continuer. Gardez visible un mot de passe, une récupération ou une autre voie prise en charge lorsque la capacité est absente, qu’une fonction facultative n’est pas supportée, que la personne refuse ou qu’une opération n’aboutit pas. Le repli fait partie de l’expérience de connexion, ce n’est pas un ajout exceptionnel.

Utilisez un texte d’interface concis et précis. Indiquez qu’une passkey peut être créée ou utilisée pour le compte actuel. Ne dites pas qu’un identifiant est déjà disponible tant qu’une cérémonie d’authentification n’a pas produit un résultat vérifié par le serveur. N’insinuez pas que l’utilisateur doit posséder un type particulier de matériel. Il peut utiliser un authentificateur externe pris en charge, un autre appareil ou une autre méthode de connexion.

Séparez les vérifications de compatibilité et les cérémonies d’identifiants dans la logique du produit. La première peut influencer la présentation. La seconde exige une requête de la partie de confiance, le traitement par le navigateur et l’authentificateur, ainsi que la participation de l’utilisateur. Après une annulation ou un échec, ramenez la personne vers un choix compréhensible au lieu d’inférer une préférence permanente. Les limites de débit, les contrôles antifraude et les politiques de sécurité du compte doivent utiliser leurs propres données documentées, et non détourner la disponibilité de WebAuthn en score de risque.

Lors des tests, couvrez les résultats plutôt que d’essayer de déduire un profil d’appareil. Incluez un navigateur où la capacité facultative est indisponible, un utilisateur qui choisit une autre méthode de connexion, une annulation, une inscription terminée et une connexion dont le serveur vérifie l’assertion. Testez les combinaisons d’origine et de RP ID prises en charge. Répétez ces vérifications après les mises à jour du navigateur ou du système d’exploitation, car le support facultatif et la gestion des erreurs peuvent changer.

Documentez la limite du service. L’authentificateur du navigateur et la partie de confiance ont des responsabilités distinctes. La partie de confiance crée la requête et vérifie la réponse sur son serveur. Le navigateur coordonne l’interaction. L’authentificateur joue son rôle dans le protocole. Une réponse de capacité ne transfère pas d’identifiants à un site, et un site ne doit pas la présenter comme un consentement à créer, récupérer ou partager un identifiant. Tout changement de compte ou transfert de données hors de la limite prévue nécessite un choix clair de l’utilisateur.

BotBrowser documente des capacités client WebAuthn contrôlées par profil. Si vous réalisez des tests autorisés de confidentialité ou de compatibilité, cela vous permet de répéter une configuration de navigateur documentée et de vérifier que votre page de connexion propose toujours une solution de repli lorsque les options de passkey diffèrent. BotBrowser ne peut pas prouver ni créer de matériel d’authentification physique, d’inscription d’identifiant ou de connexion vérifiée, et il ne contrôle pas les règles d’origine et de RP ID de votre partie de confiance, la vérification côté serveur ni la politique de conservation. Validez votre configuration prise en charge au regard des définitions publiques de WebAuthn et de votre propre parcours de compte. Le guide de gestion des profils donne des conseils généraux pour gérer les profils sans transformer un réglage en affirmation d’identité.

Sources

• W3C Web Authentication: WebAuthn Level 3: la section 5.1.6 définit la méthode de disponibilité de l’authentificateur de plateforme vérifiant l’utilisateur ; la section 5.1.7 définit les capacités du client ; la section 5.1 et le modèle de sécurité décrivent les contextes sécurisés, les origines, les réponses et le périmètre du RP ID.
• MDN: Web Authentication API: présentation destinée au navigateur de l’inscription, de l’authentification et des passkeys.
• MDN: PublicKeyCredential: avis sur les contextes sécurisés et méthodes statiques de PublicKeyCredential, notamment la médiation conditionnelle et la disponibilité de l’authentificateur de plateforme vérifiant l’utilisateur.

Conclusion pratique

Décidez ce que chaque réponse a le droit de changer avant de la brancher sur un écran. Un true de isUserVerifyingPlatformAuthenticatorAvailable() permet de mettre le bouton passkey en avant, un true de isConditionalMediationAvailable() permet d'activer la voie conditionnelle de navigator.credentials.get(), et les deux laissent le mot de passe et les voies de récupération en place. Aucun des deux ne justifie de masquer une voie, d'écrire un marqueur de compte ou de conclure que la récupération devient inutile.

Testez ensuite des issues et non des appareils. Couvrez un navigateur où la méthode optionnelle manque, une personne qui choisit le mot de passe, une cérémonie annulée, une inscription qui aboutit et une connexion que le serveur vérifie contre le défi signé et votre identifiant RP. Ne consignez que la branche et l'issue, et laissez les champs de diagnostic expirer avec le dossier.

Si la livraison comprend une configuration des capacités du client pilotée par profil, rejouez la même page dessus et confirmez que le repli apparaît encore lorsque la prise en charge des passkeys diffère. Notez la compilation du navigateur, la révision de profil, l'origine et l'identifiant RP avec ce résultat, et présentez-le comme une configuration prise en charge et non comme une affirmation sur tout authentificateur qu'un visiteur peut apporter.