Passkeys et WebAuthn : le parcours de connexion dans le navigateur
Suivez une passkey de son enregistrement à la connexion, découvrez ce que vérifient le navigateur et le serveur, et préparez portabilité, récupération et solutions accessibles.
Vous voulez la documentation structurée pour Identité ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Une connexion par passkey est un flux d’authentification à clé publique coordonné par un site, un navigateur, un authentificateur et un serveur. Lors de l’enregistrement, l’authentificateur crée un identifiant lié à la partie utilisatrice et le serveur conserve sa clé publique. Lors de la connexion, le serveur émet un nouveau défi, le navigateur demande à un authentificateur disponible d’utiliser la clé privée correspondante, puis le serveur vérifie la réponse signée avant de créer une session. Le navigateur aide à coordonner le choix de l’utilisateur et les limites de sécurité ; il ne décide pas si le compte est autorisé.
La spécification Web Authentication du W3C définit les opérations d’identifiant et le modèle de données exposés par le navigateur. Le guide MDN de Web Authentication explique les interfaces JavaScript, tandis que la présentation des passkeys de la FIDO Alliance décrit leur utilisation sur les appareils et dans les gestionnaires d’identifiants. Ces sources permettent de distinguer un moyen de prouver le contrôle d’un identifiant pour un site d’un document d’identité portable ou d’une garantie que chaque appareil présentera le même identifiant.
Ce Que Représente Une Passkey Pour Le Navigateur
Une passkey est un identifiant WebAuthn découvrable. Elle repose sur une paire de clés : la clé privée reste dans un authentificateur ou un gestionnaire d’identifiants, et la partie utilisatrice conserve la clé publique associée ainsi qu’un identifiant de credential. L’interface WebAuthn du navigateur permet à un site de demander la création ou l’utilisation d’un identifiant avec navigator.credentials.create() et navigator.credentials.get(). Le navigateur et l’authentificateur gèrent la cérémonie visible par l’utilisateur ; le site doit toujours valider le résultat et prendre une décision concernant le compte.
La partie utilisatrice (RP, pour relying party) est le site ou service qui demande l’authentification de son utilisateur. Son origine et son RP ID délimitent l’identifiant WebAuthn. Un site ne peut pas simplement demander au navigateur d’utiliser cet identifiant pour une origine sans rapport. WebAuthn est conçu pour les contextes sécurisés, les navigateurs traitant localhost comme une exception de développement. Les cadres intégrés ou d’une autre origine sont soumis à des restrictions de politique supplémentaires ; ils n’obtiennent pas un accès illimité au seul motif que la page principale y a accès.
Le mot « passkey » désigne une expérience d’identifiant, pas un mode de stockage universel. Un fournisseur peut synchroniser un identifiant entre les appareils d’un compte, le laisser lié à un appareil ou à une clé de sécurité, ou permettre une cérémonie entre appareils. Ces options ont des disponibilités et des voies de récupération différentes. La présence d’une API, la disponibilité d’un authentificateur de plateforme ou le retour d’un identifiant par le navigateur n’établissent pas l’identité civile d’une personne, ne prouvent pas qui a touché un appareil partagé et ne révèlent pas si un compte existe sur un site donné.
Il faut aussi distinguer la présence de l’utilisateur de sa vérification. La présence signifie que l’authentificateur a observé une interaction ; la vérification signifie qu’il a appliqué un contrôle local, comme un code PIN, le code de l’appareil ou une biométrie. La partie utilisatrice peut demander une préférence de vérification et doit contrôler les indicateurs retournés au regard de sa politique. Dans l’authentification WebAuthn ordinaire, le serveur ne reçoit pas de gabarit biométrique. Il reçoit des données de protocole permettant de vérifier la signature et les propriétés de l’identifiant.
Les sites devraient décrire le résultat par étapes. « Passkey disponible » ne signifie pas « passkey enregistrée » ; « identifiant renvoyé » ne signifie pas « compte authentifié » ; et « signature valide » ne signifie pas « utilisateur autorisé pour toute action ». Cette séparation évite de présenter le résultat de façon excessive et facilite le diagnostic. Pour les implications de confidentialité des signaux de capacité du navigateur, consultez le guide sur le fingerprinting WebAuthn ; cet article porte plutôt sur l’enregistrement, la connexion et la récupération. Le guide général de connexion par Credential Management traite des mots de passe et identifiants fédérés médiés par le navigateur, pas des détails du protocole WebAuthn.
Enregistrer Un Identifiant Sans Promesse Excessive
L’enregistrement commence par une action claire de l’utilisateur, par exemple choisir « Créer une passkey » dans les paramètres de sécurité du compte. Le serveur crée un défi d’enregistrement à courte durée de vie et renvoie les options requises par le navigateur : défi, RP ID et nom d’affichage, identifiant de l’utilisateur, algorithmes de clé publique acceptés, préférences d’authentificateur et éventuels identifiants existants à exclure. Comme une passkey doit être découvrable, la requête doit exiger un identifiant découvrable, par exemple avec authenticatorSelection.residentKey: "required" ; il ne faut pas accepter silencieusement un identifiant non découvrable en le qualifiant de passkey. Le serveur contrôle le défi et son lien avec le compte ; le client ne doit pas inventer ou réutiliser silencieusement l’état d’enregistrement.
La page transmet ces options à navigator.credentials.create({ publicKey }). Le navigateur vérifie si le contexte, les politiques et les authentificateurs disponibles autorisent la demande, puis affiche sa propre interface. L’utilisateur peut choisir un appareil ou un gestionnaire d’identifiants, le déverrouiller et confirmer. Avec residentKey: "required", l’enregistrement doit créer un identifiant découvrable ou échouer ; l’incapacité d’une plateforme à satisfaire la demande ne justifie pas de l’assouplir silencieusement. L’utilisateur peut annuler, changer de méthode ou rencontrer une restriction de plateforme. La page doit traiter ces issues comme normales et préserver la tâche de configuration du compte.
Lorsque la cérémonie réussit, le navigateur renvoie une réponse contenant des données client et un objet d’attestation. L’application transmet cette réponse au serveur avec l’état identifiant l’enregistrement en attente. Le serveur vérifie que le défi correspond et n’a pas expiré, que l’origine est autorisée, que le hachage du RP ID est attendu et que la réponse présente le type et les données d’identifiant prévus. Il vérifie aussi que l’identifiant peut être associé au bon compte et que la politique d’enregistrement exigeait un identifiant découvrable ; lorsque la réponse prise en charge expose les propriétés de l’identifiant, il confirme ce résultat avant d’enregistrer la passkey. Il ne valide l’attestation que dans la mesure exigée par sa politique documentée.
L’attestation peut révéler des informations sur la provenance de l’authentificateur. Un site ne devrait pas demander ni conserver davantage de données d’attestation que ne le justifient son modèle de menace et son avis aux utilisateurs. Beaucoup de services grand public peuvent accepter une large gamme d’authentificateurs au lieu d’identifier les modèles. Une politique plus restrictive peut exclure des utilisateurs légitimes, créer des obligations supplémentaires concernant les données et devenir obsolète lorsque les plateformes évoluent. Si une entreprise a une véritable exigence de niveau d’assurance, elle doit l’expliquer avant l’enregistrement et tester le parcours sur les appareils pris en charge.
Après validation, le serveur conserve l’identifiant de credential, la clé publique, le lien avec le compte et uniquement les métadonnées nécessaires aux vérifications et à la gestion futures. Il ne doit pas conserver de clé privée ; WebAuthn ne la renvoie pas au site. Un compteur peut être présent, mais son comportement varie selon les authentificateurs et les identifiants synchronisés ; ne traitez pas une simple valeur croissante comme un détecteur universel de vol. Consultez la spécification actuelle et le comportement documenté de l’authentificateur avant de choisir les contrôles de risque.
La page ne doit annoncer l’ajout de la passkey qu’après confirmation d’un identifiant découvrable selon la politique d’enregistrement. Si l’application ne peut pas confirmer cette propriété, elle ne doit pas qualifier le résultat de passkey ; elle explique que cette méthode est indisponible et propose une alternative claire et prise en charge. Affichez un nom compréhensible, comme « Cet appareil » ou une étiquette choisie par l’utilisateur, une date d’ajout si elle est utile, et une option de suppression ou de renommage. Ne lui associez pas de caractéristiques matérielles ou d’identité déduites. Les paramètres de sécurité devraient préciser que supprimer l’identifiant du site ne supprime pas nécessairement la copie gérée par un fournisseur dans l’écosystème de l’appareil ; l’utilisateur devra peut-être aussi gérer cet identifiant auprès du fournisseur.
S’Authentifier Avec Un Nouveau Défi
La connexion suit la même répartition des responsabilités. L’utilisateur choisit l’option de connexion par passkey, et le serveur génère un défi inédit et imprévisible, assorti d’une durée de validité limitée. Il choisit aussi le RP ID accepté, la politique d’identifiants, l’exigence de vérification de l’utilisateur et le contexte de compte ou de transaction à lier à la cérémonie. Dans un parcours avec saisie préalable du nom d’utilisateur, le serveur peut limiter les identifiants autorisés à ceux associés au compte. Dans un parcours sans nom d’utilisateur avec identifiants découvrables, l’authentificateur peut renvoyer un identifiant et un user handle que le serveur doit résoudre selon une politique de compte explicite.
La page appelle navigator.credentials.get({ publicKey }). Le navigateur peut afficher un sélecteur de compte ou une interface d’autocomplétion des passkeys si la plateforme et les règles de médiation le permettent. L’utilisateur choisit ou déverrouille un authentificateur, qui signe des données de protocole associées au défi et à la partie utilisatrice. Pour une utilisation entre appareils, la personne peut sélectionner un téléphone ou un autre authentificateur depuis le navigateur d’un autre appareil grâce à une cérémonie médiée. Les détails dépendent du navigateur, du système, du fournisseur d’identifiants et des transports disponibles ; l’application ne doit pas promettre la même fenêtre ou le même transport partout.
La réponse d’assertion comprend des données client, des données d’authentificateur, un identifiant de credential et une signature. Le serveur vérifie que le défi est bien celui qu’il a émis, qu’il est encore valide et qu’il n’a pas déjà été consommé. Il contrôle le type des données client, l’origine autorisée, le hachage du RP ID, le lien entre identifiant et compte, la signature à l’aide de la clé publique enregistrée et l’état de vérification lorsque la politique l’exige. Il applique ensuite l’état du compte, l’autorisation, les limites de débit et les contrôles de risque avant de créer une session. Une signature valide est un élément de cette décision, pas une session à elle seule.
Le cycle de vie du défi demande de l’attention. Générez-le avec une source cryptographiquement sûre, liez-le à la connexion ou à l’action sensible visée, faites-le expirer rapidement et refusez toute réutilisation. Ne le placez pas dans des URL, des données analytiques ou des journaux de support. Protégez l’échange avec le transport sécurisé normal de l’application et les contrôles de session côté serveur. Si la vérification échoue, ne faites pas confiance à un nom d’utilisateur, à une étiquette d’identifiant ou à un indicateur de réussite envoyé par le navigateur.
Ne confondez pas les détails d’implémentation avec une personne. Un credential ID identifie un élément dans le système de comptes de la partie utilisatrice, pas une identité globale. Le user handle doit être opaque et limité au service. Une indication de transport peut aider le navigateur à choisir un chemin, mais elle ne prouve pas qu’un authentificateur est proche ou qu’un appareil appartient à une personne nommée. La sélection du compte et l’autorisation doivent s’appuyer sur les enregistrements serveur plutôt que sur les étiquettes d’appareil ou les capacités du navigateur.
Prévoir La Portabilité Et La Récupération
Certaines passkeys sont synchronisées entre les appareils d’un utilisateur par un fournisseur d’identifiants. Les fournisseurs peuvent employer un chiffrement de bout en bout et des protections de récupération de compte, mais leur comportement, leur disponibilité et leur configuration varient. Un site ne doit pas garantir qu’un identifiant créé sur un téléphone apparaîtra immédiatement sur un autre, que chaque fournisseur fonctionnera avec chaque plateforme ou qu’un service de synchronisation sera toujours joignable. Orientez les utilisateurs vers la documentation actuelle du fournisseur pour récupérer leur compte ou leur synchronisation au lieu d’inspecter ou de réparer son état privé.
D’autres identifiants restent liés à un appareil, par exemple une clé de sécurité ou un authentificateur dont la clé privée n’est pas synchronisée. Ils peuvent fournir un second facteur durable ou une option contrôlée par une organisation, mais la perte ou la casse de l’appareil impose à la partie utilisatrice une autre voie de récupération. L’authentification entre appareils constitue encore un autre cas : l’utilisateur se sert d’un appareil proche qui détient la passkey pour terminer une connexion commencée ailleurs. Un QR code ou un échange de proximité contribue à établir la cérémonie, mais ne prouve pas à lui seul que l’utilisateur a passé la vérification du serveur. Ne réduisez pas synchronisation, sauvegarde et usage entre appareils à une promesse « fonctionne partout ».
La récupération du compte et celle du fournisseur d’identifiants sont deux tâches distinctes. La récupération du fournisseur rétablit l’accès au gestionnaire ou à son ensemble d’identifiants chiffré. La récupération de la partie utilisatrice rétablit l’accès à un compte de service lorsqu’aucune passkey inscrite ne peut être utilisée. Le site ne peut généralement ni réparer un compte fournisseur perdu ni retrouver une clé privée manquante. Sa politique peut proposer une autre passkey, une clé de sécurité déjà inscrite, des codes de récupération, une vérification d’identité approuvée ou un parcours de support soigneusement conçu. Chaque voie doit offrir un niveau d’assurance adapté à la valeur du compte et à l’action à récupérer.
Proposez une récupération dès l’enregistrement, pas seulement après le blocage de l’utilisateur. Encouragez l’ajout d’un deuxième identifiant ou d’une méthode de récupération appropriée et expliquez où elle est conservée. Pour les comptes de valeur élevée, exigez une vérification renforcée avant de remplacer tous les authentificateurs, de modifier les coordonnées de récupération ou de désactiver une méthode existante. Lorsque la politique le permet, gardez les anciens identifiants actifs jusqu’à confirmation du remplacement et avertissez clairement l’utilisateur après les changements sensibles. Le support ne doit pas pouvoir contourner les mêmes contrôles de compte au seul motif qu’un appelant connaît des informations publiques de profil.
Les écrans de récupération doivent aussi résister à l’énumération de comptes. Une réponse publique de connexion ou de récupération ne doit pas révéler si une adresse ou un nom donné possède une passkey. Dans la mesure du possible, utilisez des messages et des délais équivalents, puis n’effectuez des étapes propres au compte qu’après une vérification adaptée. Ne consignez pas les réponses passkey ni les secrets de récupération dans les données analytiques, les tickets de support, les captures d’écran ou le texte d’erreur copié. Gardez une trace minimale et auditable de l’étape et du résultat du parcours.
Rendre Les Demandes, L’Annulation Et Les Alternatives Accessibles
Le navigateur ou le système contrôle une grande partie de la fenêtre d’authentificateur, mais le site reste responsable de l’expérience autour de celle-ci. Expliquez simplement ce qu’est une passkey avant d’ouvrir la fenêtre. Nommez le compte et l’action, indiquez que le navigateur peut demander de choisir ou de déverrouiller un identifiant, et laissez une alternative visible. Ne lancez pas une demande d’identifiant au seul chargement de la page ou à l’expiration d’un minuteur invisible. Un bouton explicite et un geste de l’utilisateur rendent l’intention compréhensible pour la personne comme pour la plateforme.
Traitez l’annulation comme une décision de l’utilisateur. Si la promesse échoue ou se termine sans identifiant utilisable, laissez la personne sur la page de connexion, préservez les informations qu’il est sûr de garder et replacez le focus sur un contrôle utile. Ne rouvrez pas immédiatement la fenêtre, n’insistez pas à répétition et n’annoncez pas que le compte est absent. Ne distinguez annulation, panne réseau et rejet serveur que si l’application peut le faire de manière fiable. Un message générique respectueux de la vie privée vaut mieux que la divulgation d’un état interne du compte ou de l’identifiant.
Un parcours accessible fonctionne au clavier, avec lecteur d’écran, agrandissement et interface traduite. Utilisez un véritable bouton portant un nom accessible décrivant l’action. Annoncez les changements d’état sans déplacer le focus de manière inattendue. Donnez aux dialogues et aux choix de compte un ordre de focus logique et une commande de fermeture claire. Ne laissez pas entendre que les passkeys exigent une empreinte digitale : la plateforme peut utiliser un PIN, le code de l’appareil, une interaction avec une clé de sécurité ou une autre vérification locale prise en charge. Prévoyez des instructions pour les personnes qui ne peuvent pas utiliser l’entrée biométrique principale de leur appareil.
L’alternative doit être une voie produit planifiée, pas une dégradation improvisée. Selon le service, il peut s’agir d’une autre passkey inscrite, d’une clé de sécurité, d’un mot de passe avec authentification multifacteur ou de la récupération du compte. Appliquez les mêmes règles d’autorisation serveur après chaque méthode et protégez l’alternative contre la force brute et l’hameçonnage. Ne changez pas de compte en silence après la sélection d’une passkey et ne supprimez pas le travail non enregistré lorsque la personne change de méthode. Une solution alternative peut être moins pratique, mais elle doit rester compréhensible, sûre et accessible aux personnes en situation de handicap.
Les diagnostics opérationnels peuvent noter des étapes générales comme options émises, cérémonie annulée, assertion reçue, vérification serveur refusée et session établie. Ne consignez pas le défi, la réponse d’identifiant, la signature, les données privées, l’ensemble des données client ou un user handle brut. Cela fournit des informations de fiabilité utiles sans transformer la télémétrie de connexion en collecte d’identifiants. Avant le déploiement, examinez la durée de conservation, les contrôles d’accès et le risque d’associer une mesure à une personne.
Maintenir La Confidentialité Et La Politique Serveur À Leur Place
La liaison de WebAuthn à l’origine et au RP ID aide à empêcher qu’un identifiant créé pour une partie utilisatrice soit utilisé comme s’il appartenait à une autre. Elle ne sécurise pas automatiquement tout système d’authentification. Le serveur doit toujours bien gérer les défis, maintenir sa liste d’origines autorisées, utiliser des cookies de session sûrs, vérifier les autorisations, limiter les tentatives, définir la récupération et surveiller le service. Le vol d’une session active diffère de celui d’une clé privée passkey ; la sécurité du compte doit couvrir le cycle de vie de l’identifiant comme celui de la session après la connexion.
Limitez les signaux collectés pendant la cérémonie. Ne faites pas d’empreinte des modèles d’authentificateur, ne conservez pas la disponibilité de l’API comme identité d’appareil, ne déduisez pas le nom d’une personne d’un sélecteur de compte et ne construisez pas de profil intersites à partir d’indications de transport. Les vérifications de capacités du navigateur servent à décider si une action doit être présentée dans l’interaction actuelle. Elles ne justifient ni la découverte de comptes, ni un score d’éligibilité, ni une affirmation sur la personne qui tient l’appareil. Demandez uniquement les options de protocole nécessaires et expliquez toute politique d’authentificateur plus restrictive avant que l’utilisateur ne la rencontre.
Les équipes d’implémentation devraient tester tout le parcours sur les combinaisons de navigateur et système réellement prises en charge : enregistrement, connexion réussie, identifiant absent ou demande refusée, défi expiré, origine incorrecte, rejet du serveur, utilisation depuis un second appareil, suppression d’identifiant et récupération. Testez également au clavier et avec lecteur d’écran, en plus du tactile. Les informations de compatibilité évoluent ; consultez les documents WebAuthn et les données de prise en charge actuels avant toute promesse. Une démonstration réussie sur un seul appareil ne prouve que ce chemin précis, pas un fonctionnement universel.
BotBrowser permet aux équipes de tester leur propre interface d’enregistrement et de connexion par passkey avec des profils de navigateur reproductibles sur les systèmes hôtes pris en charge. BotBrowser ne contrôle pas directement la médiation du navigateur, les authentificateurs du système, les vérifications biométriques locales ni les décisions du serveur ; il ne crée, ne stocke, ne synchronise, ne récupère et n’authentifie pas les passkeys. Utilisez-le pour comparer un parcours applicatif autorisé, en considérant le navigateur, le fournisseur d’authentificateur et le backend comme responsables distincts du résultat.
Le contrat pratique est simple : l’utilisateur choisit de commencer ; le navigateur et l’authentificateur réalisent une cérémonie liée à la partie utilisatrice ; le serveur vérifie la réponse signée et décide de créer ou non une session ; le service fournit des alternatives accessibles et une récupération. Lorsque chaque couche a une responsabilité définie, une passkey peut simplifier la connexion sans entraîner d’affirmations infondées sur la portabilité, l’identité, la confidentialité ou la récupération.
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.