Qu’est-ce que WebAuthn ? Définition, exemples et bonnes pratiques

WebAuthn est la norme du W3C pour une authentification sans mot de passe et résistante au phishing. Découvrez son fonctionnement, les erreurs de déploiement courantes et les bonnes pratiques en entreprise.

Qu’est-ce que WebAuthn ?

Les mots de passe échouent. Ils sont hameçonnés, bourrés, pulvérisés et déversés. Le Data Breach Investigations Report (DBIR) 2026 de Verizon a constaté un abus d’identifiants dans 39 % de l’ensemble des violations, soit la technique la plus répandue de son jeu de données, raison pour laquelle les défenseurs priorisent les contrôles qui retirent les mots de passe du parcours de connexion. WebAuthn est la norme du World Wide Web Consortium (W3C) conçue pour faire exactement cela.

WebAuthn, abréviation de Web Authentication, est une norme web du W3C qui définit une API de navigateur pour créer et utiliser des identifiants forts, basés sur des clés publiques, afin d’authentifier les utilisateurs auprès d’applications web. Au lieu d’échanger des secrets partagés comme des mots de passe, WebAuthn utilise la cryptographie asymétrique : votre authentificateur génère une paire de clés unique par site, conserve la clé privée verrouillée dans un matériel sécurisé et ne partage avec le serveur que la clé publique.

La spécification du W3C la définit formellement comme « une API permettant la création et l’utilisation, par des applications web, d’identifiants forts, attestés, délimités et basés sur des clés publiques, dans le but d’authentifier fortement les utilisateurs ». En pratique, cela signifie que vous pouvez vous connecter à des applications web à l’aide d’une empreinte digitale, d’un déverrouillage facial ou d’une clé de sécurité physique, et que le serveur ne reçoit jamais rien qu’un attaquant pourrait réutiliser.

WebAuthn est un composant central du projet FIDO2, développé en coordination avec la Fast Identity Online (FIDO) Alliance. FIDO2 associe WebAuthn (la couche API du navigateur) à CTAP (Client to Authenticator Protocol), qui gère la communication entre votre dispositif d’authentification et le navigateur via USB, near-field communication (NFC) ou Bluetooth Low Energy (BLE). Ensemble, ils constituent la base de l’authentification sans mot de passe et résistante au phishing sur le web.

Deux incidents montrent le coût du modèle fondé sur les mots de passe à grande échelle. En 2021, des attaquants ont accédé à Colonial Pipeline via un profil de réseau privé virtuel (VPN) hérité qui n’était pas censé être utilisé, comme le PDG de l’entreprise l’a déclaré au Sénat américain. Colonial a arrêté le pipeline pour contenir l’attaque et a payé une rançon de 4,4 millions de dollars à un affilié de DarkSide, l’opération de ransomware couverte dans un avis de la CISA. Le Department of Justice a ensuite saisi 2,3 millions de dollars de cette somme. En 2023, MGM Resorts a signalé un impact financier négatif estimé à 100 millions de dollars à la suite d’un cyberincident ayant commencé par de l’ingénierie sociale visant les workflows d’identité, selon un 8-K d’octobre 2023. Dans les deux cas, tout reposait sur un secret réutilisable. WebAuthn le retire du parcours de connexion.

WebAuthn vs authentification traditionnelle

L’authentification traditionnelle repose sur des secrets partagés. Les mots de passe, les codes à usage unique et les approbations push transmettent tous des données qu’un attaquant peut intercepter, rejouer ou hameçonner en temps réel. WebAuthn change le modèle en remplaçant les secrets partagés par une cryptographie à clé publique, où la clé privée ne quitte jamais le matériel de votre authentificateur et où rien de réutilisable ne traverse le réseau.

Les différences comptent surtout aux points où les méthodes traditionnelles échouent :

• Résistance au phishing. L’authentification basée sur les mots de passe et sur les OTP peut être capturée par des proxys de phishing en temps réel. Les identifiants WebAuthn sont liés cryptographiquement au domaine d’origine, de sorte qu’un identifiant enregistré sur login.example.com ne s’authentifiera pas sur login-example.com ni sur aucun autre domaine ressemblant. Le navigateur applique cela au niveau du protocole, indépendamment du jugement de l’utilisateur.
• Exposition côté serveur. Les systèmes traditionnels stockent des hachages de mots de passe ou des secrets partagés qui deviennent des cibles de grande valeur lors de violations de bases de données. WebAuthn ne stocke que des clés publiques. Une compromission complète du serveur ne donne à un attaquant rien qu’il puisse utiliser pour usurper l’identité d’un utilisateur.
• Réutilisation des identifiants. Les utilisateurs réutilisent leurs mots de passe entre services, ce qui rend le credential stuffing efficace à grande échelle. WebAuthn génère une paire de clés unique par partie de confiance, de sorte qu’un identifiant compromis sur un service n’a aucune valeur sur un autre.
• Compromis entre friction utilisateur et sécurité. Des mots de passe plus longs et une rotation fréquente améliorent la sécurité sur le papier, mais dégradent l’utilisabilité. WebAuthn supprime ce compromis : une empreinte digitale ou un déverrouillage facial fournit une assurance d’authentification plus forte que n’importe quelle politique de mot de passe, avec moins de friction pour l’utilisateur.

L’effet net est que WebAuthn élimine les trois vecteurs responsables de la plupart des violations liées aux identifiants : le phishing, le vol côté serveur et la réutilisation intersites. Comprendre ces différences pose les bases de la manière dont les composants du protocole appliquent ces propriétés.

Composants clés de WebAuthn

WebAuthn fonctionne selon une architecture à trois parties définie par la spécification W3C.

Authentificateur : Il s’agit de l’entité cryptographique qui génère les paires de clés et signe les assertions d’authentification. Les authentificateurs se répartissent en deux catégories :

• Les authentificateurs de plateforme sont intégrés au système d’exploitation de votre appareil : Windows Hello, Touch ID, Face ID. Ils s’enrôlent avec très peu de friction, mais sont perdus si l’appareil est perdu.
• Les authentificateurs itinérants (cross-platform) sont des dispositifs matériels portables comme les YubiKeys et les clés de sécurité FIDO. Ils fonctionnent sur plusieurs appareils mais nécessitent une distribution physique et une gestion d’inventaire.

Quel que soit le type choisi, le modèle de sécurité reste le même : l’authentificateur crée une paire de clés unique par partie de confiance, et la clé privée ne quitte jamais la frontière sécurisée de l’authentificateur.

Relying Party (RP) : Il s’agit de votre application web : du JavaScript côté client qui invoque l’API WebAuthn, plus un composant côté serveur qui gère le stockage et la vérification des identifiants. Le RP ne stocke que la clé publique. L’ID RP, généralement votre nom de domaine, sert d’ancrage cryptographique pour la liaison à l’origine.

User Agent (navigateur) : Le navigateur sert d’intermédiaire pour toutes les interactions entre les authentificateurs et les parties de confiance. Il applique les politiques d’origine, empêche l’usage abusif des identifiants entre domaines et préserve la confidentialité des utilisateurs : les identifiants enregistrés sur une origine ne peuvent pas être utilisés par une autre, ce qui bloque le phishing au niveau du protocole.

WebAuthn définit également un cadre d’attestation qui permet aux authentificateurs de prouver cryptographiquement leur authenticité lors de l’enregistrement. Votre entreprise peut alors vérifier que les identifiants proviennent de modèles d’authentificateurs approuvés par l’IT et de confiance, plutôt que d’appareils inconnus ou grand public. Le FIDO Metadata Service fournit un mécanisme en direct de révocation et d’avis pour les modèles d’authentificateurs.

Une fois que vous connaissez les acteurs et les frontières de confiance, vous pouvez cartographier les deux cérémonies et voir exactement où la vérification peut échouer.

Fonctionnement de WebAuthn

WebAuthn définit deux cérémonies cryptographiques : l’enregistrement (création d’identifiant) et l’authentification (vérification d’assertion). Toutes deux suivent un protocole challenge-response.

1. Enregistrement (création d’identifiant) : Votre serveur génère un challenge aléatoire cryptographiquement et l’envoie au client avec les informations de la partie de confiance, les détails du compte utilisateur et les algorithmes cryptographiques acceptables. Le client appelle navigator.credentials.create(). L’authentificateur demande le consentement explicite de l’utilisateur, génère une nouvelle paire de clés asymétriques et renvoie un objet d’attestation contenant la clé publique, le challenge signé, l’ID d’identifiant et (éventuellement) une chaîne de certificats d’attestation. Votre serveur vérifie l’attestation, valide la signature, confirme que la clé publique correspond aux algorithmes demandés et stocke la clé publique de l’identifiant, l’ID d’identifiant et le compteur de signature. Garde-fou critique : même avec des paramètres identiques, navigator.credentials.create() génère un nouvel identifiant à chaque appel. Vous devez utiliser le paramètre excludeCredentials pour empêcher les enregistrements en double.
2. Authentification (vérification d’assertion) : Votre serveur génère un nouveau challenge et l’envoie au client avec une liste des ID d’identifiants autorisés. Le client appelle navigator.credentials.get(). L’authentificateur vérifie la présence ou l’identité de l’utilisateur (selon votre politique), puis signe le challenge avec la clé privée stockée. Votre serveur récupère la clé publique stockée, vérifie la signature de l’assertion, valide la correspondance du challenge, vérifie les indicateurs de présence/vérification de l’utilisateur, confirme que l’origine et l’ID RP correspondent, et vérifie que le compteur de signature a été incrémenté.

La vérification du compteur de signature constitue votre défense contre les authentificateurs clonés. Si le compteur ne s’incrémente pas comme prévu, vous avez la preuve d’une duplication d’identifiant.

Pour la conformité AAL2, vous devez imposer la User Verification (UV), et pas seulement la User Presence (UP). Selon les directives sur les authentificateurs synchronisables, les vérificateurs doivent indiquer que l’UV est préférée et inspecter les réponses pour confirmer que l’indicateur UV est défini.

Comment les organisations déploient WebAuthn

Voir où WebAuthn fonctionne en production répond à la question que la plupart des évaluateurs posent réellement : cela a-t-il été prouvé à grande échelle ?

• Google Accounts est la référence la plus claire. Google a commencé à déployer les passkeys en mai 2023 et les a rendues par défaut pour les comptes personnels en octobre 2023. Dans l’année suivant le lancement, les passkeys avaient été utilisées plus d’un milliard de fois sur plus de 400 millions de comptes, et Google a indiqué que les passkeys étaient déjà utilisées pour l’authentification plus souvent que les OTP par SMS et les applications d’authentification combinées au quotidien.
• GitHub a cité WebAuthn comme l’option 2FA la plus forte disponible lorsqu’il a rendu la 2FA obligatoire en 2023 pour tous les contributeurs, qualifiant les clés de sécurité physiques et les authentificateurs de plateforme comme Windows Hello et Face ID de méthodes les moins vulnérables au phishing.
• Les plateformes commerciales ont suivi : Amazon, PayPal, Shopify, DocuSign et Kayak, qui a réduit de 50 % le temps moyen d’inscription et de connexion, ont toutes déployé une connexion reposant sur WebAuthn. Ces déploiements confirment que WebAuthn fonctionne à l’échelle grand public, gère les workflows de récupération et s’intègre aux architectures standard de fournisseurs d’identité.

Une fois les cérémonies et les déploiements réels compris, la décision suivante consiste à déterminer quel type d’authentificateur convient à votre environnement.

Types d’authentificateurs WebAuthn

Le choix de votre authentificateur façonne le niveau d’assurance de sécurité, l’expérience utilisateur et la surcharge opérationnelle de votre déploiement WebAuthn. Chaque type comporte des compromis distincts qui comptent pour la planification en entreprise.

1. Les authentificateurs de plateforme sont intégrés au système d’exploitation et au matériel de l’appareil. Windows Hello utilise un code PIN adossé à un Trusted Platform Module (TPM), la reconnaissance faciale ou l’empreinte digitale. Les appareils Apple utilisent Touch ID ou Face ID adossés au Secure Enclave. Les appareils Android utilisent l’empreinte digitale ou le déverrouillage facial via Google Play Services. Les authentificateurs de plateforme 1carry la plus faible friction d’enrôlement parce que les utilisateurs disposent déjà du matériel, et la vérification biométrique satisfait aux exigences de user verification (UV) pour la conformité AAL2 sans étapes supplémentaires. La limite est que les identifiants sont liés à l’appareil. Si un utilisateur perd son ordinateur portable ou son téléphone, ces identifiants sont perdus sauf si vous utilisez des passkeys synchronisées.
2. Les authentificateurs itinérants (cross-platform) sont des jetons matériels portables, tels que les YubiKeys, les clés Feitian BioPass ou d’autres clés de sécurité FIDO2, qui se connectent via USB, NFC ou BLE. Ils fonctionnent sur plusieurs appareils et systèmes d’exploitation, ce qui en fait le choix standard pour les accès privilégiés, les environnements de postes de travail partagés et les cas d’usage à haute assurance. Le compromis réside dans la logistique de distribution : vous devez approvisionner, expédier, inventorier et gérer des dispositifs physiques, et les utilisateurs doivent les transporter.
3. Les passkeys synchronisées constituent une catégorie plus récente dans laquelle les identifiants WebAuthn se synchronisent via un gestionnaire de mots de passe de plateforme (iCloud Keychain, Google Password Manager ou un gestionnaire tiers comme 1Password). Les passkeys synchronisées réduisent le problème de récupération en cas de perte d’appareil, car l’identifiant survit sur tout appareil connecté au même compte. Pour la plupart des utilisateurs en entreprise, cela supprime le principal point de friction dans l’adoption de WebAuthn. Le compromis est que la sécurité de votre authentification dépend désormais en partie de la sécurité du compte de plateforme qui héberge l’identifiant synchronisé. Pour les environnements à haute assurance, les identifiants liés à l’appareil avec des clés de secours gérées par l’IT restent le choix le plus solide.

La plupart des déploiements en entreprise utilisent une combinaison : des authentificateurs de plateforme pour l’usage quotidien, une clé itinérante comme sauvegarde enregistrée, et des passkeys synchronisées lorsque le profil de risque le permet. Choisir la bonne combinaison dépend de vos exigences d’assurance, de votre population d’utilisateurs et du niveau de surcharge opérationnelle que vous pouvez absorber.

La décision concernant l’authentificateur influence directement les propriétés de sécurité que vous obtenez, ce que couvre la section suivante.

Avantages de sécurité de WebAuthn

WebAuthn offre des avantages de sécurité concrets en matière de résistance au phishing, d’exposition côté serveur, de conformité réglementaire et de prévention des attaques intersites :

• Résistance au phishing au niveau du protocole. WebAuthn lie cryptographiquement les identifiants à l’origine. Le commentaire de la FIDO Alliance au NIST avertissait que les attaquants ont rattrapé les authentificateurs AAL2 qui ne résistent pas au phishing. WebAuthn comble cet écart.
• Aucun secret partagé sur le serveur.Le modèle de cryptographie à clé publique de FIDO2 supprime la nécessité de partager des secrets entre le fournisseur d’identité et l’authentificateur, ce que le NIST SP 800-63B-4 appelle la résistance à la compromission du vérificateur. Une violation complète de base de données ne fournit rien qu’un attaquant puisse rejouer.
• Alignement réglementaire. WebAuthn satisfait aux exigences AAL2 résistantes au phishing du NIST SP 800-63B-4. Le mémorandum M-22-09 de l’Office of Management and Budget (OMB) du gouvernement américain cite directement la norme W3C Web Authentication comme approche résistante au phishing pour les agences fédérales. Les organisations réglementées disposent d’une voie de conformité claire et vérifiable.
• Élimination des attaques liées au facteur humain. Le DBIR 2026 de Verizon   a attribué le facteur humain à 62 % des violations. WebAuthn supprime deux surfaces d’attaque humaines critiques : le choix de mots de passe faibles et la vulnérabilité au phishing. Les utilisateurs ne peuvent pas choisir de mauvais mots de passe lorsqu’il n’y a pas de mots de passe.
• Prévention du credential stuffing intersites. Chaque identifiant est cryptographiquement délimité à un domaine spécifique, ce qui rend le credential stuffing beaucoup moins efficace entre services.

Ces propriétés de sécurité ne sont pas théoriques. Les organisations qui ont déployé WebAuthn à grande échelle les ont déjà validées en production, et les cas d’usage couvrent presque tous les secteurs d’activité.

Cas d’usage courants de WebAuthn

L’adoption de WebAuthn se concentre dans les scénarios où les attaques basées sur les identifiants ont l’impact métier le plus élevé. Ce sont les modèles de déploiement qui apparaissent le plus fréquemment dans les environnements de production.

• Accès privilégiés et consoles d’administration. Les portails VPN, les consoles de gestion cloud et les panneaux d’administration d’infrastructure sont les cibles de plus grande valeur pour le vol d’identifiants. Déployer WebAuthn comme second facteur obligatoire, ou comme méthode principale sans mot de passe, pour ces points d’accès supprime la surface d’attaque que les kits de phishing et les dumps d’identifiants exploitent le plus agressivement. Il s’agit généralement de la première phase de tout déploiement en entreprise.
• Connexion orientée client pour les services financiers et la santé. Les secteurs réglementés où la compromission d’identifiants déclenche des notifications de violation, des sanctions réglementaires et des pertes financières directes adoptent les passkeys pour l’authentification des clients. Les applications bancaires, les portails patients et les plateformes d’assurance utilisent WebAuthn pour satisfaire à la fois aux exigences de conformité (PCI DSS, contrôles d’accès HIPAA) et à l’objectif opérationnel de réduction de la fraude par prise de contrôle de compte.
• Environnements de postes partagés et de kiosques. Les hôpitaux, les ateliers de fabrication et les opérations de vente au détail utilisent des terminaux partagés où la connexion par mot de passe est lente et sujette à l’observation par-dessus l’épaule. Les authentificateurs itinérants (clés de sécurité compatibles NFC ou solutions par badge) authentifient les utilisateurs en quelques secondes sans qu’aucun identifiant ne soit saisi sur un appareil partagé.
• Single sign-on (SSO) pour les effectifs. Déployer WebAuthn au niveau du fournisseur d’identité (IdP), via des plateformes comme Okta, Azure AD ou Ping Identity, protège chaque application en aval dans un environnement fédéré avec un seul enrôlement. C’est la voie la plus efficace vers une large couverture, car vous déployez WebAuthn une fois au niveau de l’IdP et chaque partie de confiance Security Assertion Markup Language (SAML) ou OpenID Connect (OIDC) hérite de l’authentification résistante au phishing.

Chacun de ces cas d’usage renforce le même principe : plus vous vous rapprochez de l’élimination des secrets réutilisables de votre flux d’authentification, moins il reste de chemins d’attaque basés sur les identifiants ouverts. Cela dit, déployer WebAuthn à grande échelle introduit une complexité opérationnelle que les équipes doivent anticiper.

Défis et limites de WebAuthn

Le modèle de sécurité de WebAuthn est solide, mais les déploiements en entreprise font apparaître une complexité opérationnelle que les équipes sous-estiment systématiquement :

• Gestion du cycle de vie des identifiants. Le principal mode d’échec dans les déploiements WebAuthn en entreprise est opérationnel, et non cryptographique. Vous avez besoin de processus documentés pour la distribution des authentificateurs, la révocation des identifiants en cas de perte d’appareil, les politiques de renouvellement et l’assistance utilisateur en cas d’échec d’authentification. Les directives FIDO sur le cycle de vie couvrent en détail les phases d’enrôlement, de récupération et de révocation.
• Sélection du type d’authentificateur. Vous êtes confronté à une décision stratégique entre les authentificateurs de plateforme (coût de distribution nul, perdus avec l’appareil), les authentificateurs itinérants (portables mais nécessitant une distribution physique) et les approches hybrides. Chacun implique des niveaux d’assurance, des exigences de récupération et une surcharge opérationnelle différents.
• Intégration des applications héritées. Toutes les applications de votre environnement ne prennent pas en charge WebAuthn nativement. Vous devez traiter l’intégration avec des protocoles de fédération comme SAML, OAuth et OpenID Connect. Il s’agit d’un défi important pour les organisations ayant des topologies complexes de fédération d’identité.
• Décisions d’architecture du serveur FIDO. Vous devez choisir entre intégrer un serveur FIDO à votre fournisseur d’identité existant, déployer un serveur FIDO autonome ou utiliser un modèle FIDO-server-as-a-service. Chaque option a un impact sur l’architecture de stockage des identifiants, les procédures de reprise après sinistre et le périmètre du déploiement. Le guide de déploiement des serveurs FIDO détaille les compromis.
• Le compromis des identifiants synchronisés. La synchronisation des passkeys via les principaux gestionnaires de mots de passe de plateforme réduit fortement la friction utilisateur, mais transfère une partie de la sécurité de l’authentification vers la sécurité du compte de plateforme. Là où les exigences d’assurance sont les plus élevées, les identifiants liés à l’appareil avec des clés de secours gérées par l’IT restent le choix le plus solide.

Au-delà de la complexité opérationnelle, certaines décisions de mise en œuvre créent une exposition plus durable :

• Considérer toute MFA comme résistante au phishing. C’est l’erreur ayant le plus fort impact. Déployer TOTP, SMS OTP ou une MFA par notification push et revendiquer une conformité résistante au phishing vous laisse exposé. Les proxys de phishing en temps réel capturent et rejouent les deux facteurs dans ces approches. Seul WebAuthn avec liaison au nom du vérificateur ou liaison de canal offre une véritable résistance au phishing.
• Autoriser l’enregistrement d’identifiants sans authentification. CVE-2021-3632 l’a démontré dans Keycloak, où n’importe qui pouvait enregistrer un nouveau dispositif de sécurité lorsqu’aucun dispositif n’existait pour un compte utilisateur. L’enregistrement doit avoir lieu dans une session déjà authentifiée ou via des processus hors bande vérifiés.
• Mauvaise conception du flux d’enrôlement. Un enrôlement laborieux crée une résistance des utilisateurs et augmente le volume de tickets de support. Votre portail d’enrôlement doit guider les utilisateurs dans l’enregistrement au sein d’une session authentifiée, fournir des instructions claires sur les authentificateurs acceptables et expliquer pourquoi certains appareils ont été rejetés.
• Absence de mécanismes de secours et de récupération. Déployer WebAuthn sans procédures de secours documentées pour la perte d’appareil, la panne matérielle ou les problèmes biométriques crée des scénarios de verrouillage. Vous avez besoin d’authentificateurs de secours préenregistrés, de codes d’accès d’urgence pour les administrateurs IT et de processus de vérification en personne.
• Déployer WebAuthn isolément de votre pile de sécurité. WebAuthn n’est pas une solution autonome. Selon le NIST SP 1800-35, il doit s’intégrer à l’évaluation continue de l’authentification, à la vérification de l’état de santé des appareils, aux politiques d’accès contextuelles et à votre infrastructure de sécurité des endpoints. Dans une architecture zero trust, WebAuthn devient l’un des signaux les plus forts que vous puissiez injecter dans les décisions d’accès.

Ces défis peuvent être résolus avec une planification adaptée. Les pratiques suivantes couvrent les décisions clés qui distinguent un déploiement prêt pour la production d’une preuve de concept.

Bonnes pratiques pour mettre en œuvre WebAuthn

Les pratiques suivantes couvrent les décisions clés qui distinguent un déploiement WebAuthn prêt pour la production d’une preuve de concept.

Imposez la user verification pour AAL2. Définissez userVerification: "required" dans les cérémonies d’enregistrement et d’authentification, et validez l’indicateur UV côté serveur. Ne vous appuyez pas sur "preferred" pour les déploiements soumis à des exigences de conformité.

Utilisez l’attestation pour appliquer la politique d’authentificateur. Vérifiez les attestations lors de l’enregistrement et n’autorisez que les authentificateurs qui répondent à vos exigences de sécurité (par exemple, certification FIDO L1+). Utilisez des listes d’autorisation basées sur l’AAGUID (identifiant de modèle d’authentificateur) et intégrez-vous au FIDO Metadata Service pour des vérifications en direct du statut des authentificateurs.

Déployez par phases. La recommandation de déploiement progressif FIDO est une approche par étapes :

1. WebAuthn comme second facteur pour les applications à haut risque (VPN, accès privilégiés, consoles d’administration)
2. Déploiement du second facteur à l’échelle de la plateforme tout en construisant le support opérationnel
3. Identifiants découvrables et flux sans mot de passe pour des populations d’utilisateurs matures
4. Sans mot de passe complet avec authentification héritée retirée pour les utilisateurs enrôlés

Cette approche vous permet de valider les workflows de politique, de support et de récupération avant de faire de WebAuthn la valeur par défaut.

Mettez en œuvre une stratégie de récupération multi-authentificateur. Enregistrez au moins deux authentificateurs par utilisateur : un principal (par exemple, authentificateur de plateforme pour l’usage quotidien) et un de secours (par exemple, clé de sécurité stockée de manière sécurisée). Affichez clairement les identifiants de récupération enregistrés dans les paramètres du compte utilisateur.

Vérifiez les compteurs de signature. Vérifiez que le compteur de signature s’incrémente de manière monotone à chaque authentification. Un compteur qui ne s’incrémente pas signale un authentificateur potentiellement cloné.

Séparez les erreurs attendues des erreurs inattendues. Suivez explicitement les erreurs WebAuthn. Regroupez NotAllowedError, AbortError et les erreurs de passkey du Credential Manager comme des signaux distincts afin de différencier la friction utilisateur des anomalies de sécurité.

Suivre ces pratiques amènera votre déploiement WebAuthn à un état prêt pour la production. Mais même un déploiement WebAuthn correctement configuré ne constitue pas une défense d’identité complète. Les attaques qui contournent entièrement WebAuthn nécessitent des contrôles qui opèrent au-delà de la cérémonie de connexion : détournement de session, mouvement latéral post-authentification et ingénierie sociale du help desk.

Comment SentinelOne renforce la sécurité des identités

WebAuthn réduit le rejeu d’identifiants, mais n’arrête pas toutes les attaques sur le chemin de l’identité que vous verrez en production. Vous devez toujours gérer le vol de jetons de session, la compromission des appareils, l’ingénierie sociale du help desk et le mouvement latéral post-authentification.

La Singularity™ Platform comble cette lacune en corrélant le contexte d’identité et d’endpoint :

• Singularity Identity détecte les comportements d’identité suspects et répond lorsque des adversaires ciblent les services d’annuaire et les workflows SSO. Elle couvre l’infrastructure d’identité que WebAuthn ne touche jamais.
• Singularity Endpoint exécute des modèles d’IA comportementaux et statiques sur l’appareil pour arrêter les malwares voleurs d’identifiants et les activités hands-on-keyboard qui contournent entièrement les contrôles de connexion. Elle signale les schémas malveillants en temps réel sans intervention humaine, ce qui compte lorsque les attaquants ciblent les sessions plutôt que les mots de passe.
• Purple AI™ raisonne sur l’ensemble de vos données de sécurité pour guider les investigations et recommander les prochaines actions. Un IDC Snapshot 2025 a constaté que les clients identifiaient les menaces 63 % plus rapidement, ce qui compte lorsque vous devez déterminer si un échec de connexion WebAuthn relevait d’une friction utilisateur ou d’une campagne de phishing active.

Ensemble, ils couvrent le chemin d’attaque sur l’identité des deux côtés de la connexion.

Si vous traitez WebAuthn comme un signal fort au sein de votre programme de défense contre le phishing et de votre workflow de réponse aux incidents, vous pouvez réduire à la fois le risque de prise de contrôle et le temps passé à prouver ce qui s’est passé.

Demander une démo pour voir comment SentinelOne comble l’écart entre l’authentification et une défense complète des identités.

Faire la visite

Bénéficiez d’une protection des identités en temps réel et d’une visibilité de bout en bout sur les environnements hybrides pour détecter les expositions, stopper l’abus d’identifiants et réduire le risque lié à l’identité.

Points clés à retenir

WebAuthn est la norme W3C pour l’authentification web sans mot de passe et résistante au phishing utilisant la cryptographie à clé publique. Elle lie cryptographiquement les identifiants à des domaines spécifiques, rendant le rejeu d’identifiants impossible sur le plan architectural. 

Un déploiement réussi en entreprise nécessite un déploiement progressif, une politique d’authentificateur fondée sur l’attestation, des stratégies de récupération multi-appareils et une intégration à votre pile de sécurité globale.

FAQ

Qu’est-ce que WebAuthn en cybersécurité ?

WebAuthn, abréviation de Web Authentication, est une norme web du W3C qui définit une API de navigateur pour créer et utiliser des identifiants forts, basés sur des clés publiques, afin d’authentifier les utilisateurs auprès d’applications web. 

Au lieu d’utiliser des mots de passe, il s’appuie sur la cryptographie asymétrique : votre authentificateur génère une paire de clés unique par site, conserve la clé privée dans un matériel sécurisé et ne partage que la clé publique avec le serveur. Cela rend le vol d’identifiants et les attaques de phishing beaucoup plus difficiles à exécuter.

Quelles attaques WebAuthn empêche-t-il ?

La principale propriété de sécurité de WebAuthn est la résistance au phishing grâce à la liaison cryptographique au domaine. Lorsque vous enregistrez un identifiant, il est lié à l’origine exacte de la partie de confiance. Lorsque vous vous authentifiez, le navigateur inclut cryptographiquement cette origine dans la réponse signée, de sorte qu’un attaquant sur un domaine ressemblant ne peut pas rejouer votre identifiant. 

Au-delà du phishing, WebAuthn élimine le vol d’identifiants côté serveur, car seules des clés publiques sont stockées, et il empêche le credential stuffing car chaque identifiant est limité à un seul domaine.

WebAuthn est-il identique à FIDO2 ?

WebAuthn et FIDO2 sont liés, mais ne sont pas identiques. FIDO2 est le projet plus large, développé par la FIDO Alliance en coordination avec le W3C, qui combine deux spécifications : WebAuthn (l’API du navigateur pour créer et vérifier des identifiants à clé publique) et CTAP (Client to Authenticator Protocol, qui gère la communication entre votre authentificateur et le navigateur via USB, NFC ou BLE). 

WebAuthn est la composante web de FIDO2. Vous implémentez WebAuthn dans votre application. CTAP s’exécute entre le matériel d’authentification et le navigateur.

Comment WebAuthn prend-il en charge la sécurité Zero Trust ?

WebAuthn fournit l’un des signaux d’authentification les plus robustes dans une architecture zero trust. Selon NIST SP 1800-35, il s’intègre à l’évaluation continue de l’authentification, à la vérification de l’état de santé des appareils et aux politiques d’accès sensibles au contexte. Étant donné que les identifiants WebAuthn résistent au phishing et sont liés au domaine, ils constituent une étape de vérification d’identité à haut niveau d’assurance qui alimente des décisions d’accès plus larges. 

En pratique, associer WebAuthn à la télémétrie des terminaux et à l’analyse comportementale offre à votre moteur de politiques un signal d’authentification plus fiable que n’importe quel mot de passe ou méthode MFA héritée.

Quels navigateurs et plateformes prennent en charge WebAuthn ?

Selon Can I Use, WebAuthn est disponible dans environ 95 % des navigateurs mondiaux. Tous les navigateurs de bureau evergreen le prennent en charge : Chrome (v67+), Firefox (v60+), Safari (v14+) et Edge (v18+). Sur mobile, Chrome pour Android, Safari sur iOS et Samsung Internet prennent tous en charge WebAuthn. 

Pour les authentificateurs de plateforme, Windows 10+ inclut Windows Hello (reconnaissance faciale, empreinte digitale, PIN via TPM), macOS/iOS 16+ prend en charge Touch ID et Face ID avec la synchronisation du trousseau iCloud pour les passkeys, et Android 9+ fournit le déverrouillage par empreinte digitale et reconnaissance faciale via Google Play Services. Des lacunes subsistent dans les anciennes versions des systèmes d’exploitation et dans certaines configurations de navigateurs d’entreprise verrouillées.

Quelle est la différence entre WebAuthn et les passkeys ?

WebAuthn est la spécification d’API du W3C que les navigateurs implémentent pour la création et l’authentification d’identifiants à clé publique. Les passkeys sont un terme orienté utilisateur pour désigner les identifiants WebAuthn, faisant souvent plus précisément référence à des identifiants synchronisés (adossés au cloud) qui se synchronisent entre vos appareils via des fournisseurs de plateforme. 

Toutes les passkeys utilisent WebAuthn en arrière-plan, mais tous les identifiants WebAuthn ne sont pas des passkeys synchronisées. Les identifiants WebAuthn liés à l’appareil restent associés à un matériel spécifique.

WebAuthn peut-il remplacer toutes les formes de MFA ?

WebAuthn peut fonctionner comme une authentification à facteur unique (possession de l’authentificateur), à deux facteurs (possession plus biométrie ou PIN), ou multifacteur selon votre configuration. 

Pour la conformité AAL2, vous devez imposer la vérification de l’utilisateur (biométrie ou PIN) et valider l’indicateur UV côté serveur. WebAuthn remplace les méthodes MFA héritées comme TOTP et SMS OTP tout en offrant une résistance au phishing plus forte que n’importe laquelle d’entre elles.

Que se passe-t-il si un utilisateur perd son authentificateur WebAuthn ?

Sans plan de récupération, il est verrouillé hors de son compte. La bonne pratique consiste à enregistrer au moins deux authentificateurs par utilisateur : un appareil principal pour l’usage quotidien et une sauvegarde stockée en toute sécurité. 

Votre processus de récupération de compte doit également inclure des codes d’accès d’urgence pour les administrateurs IT et une procédure de vérification en personne pour les environnements à haut niveau d’assurance où les authentificateurs de secours ne sont pas disponibles.

WebAuthn fonctionne-t-il avec les systèmes d’identité fédérée ?

Oui, mais l’intégration nécessite une planification. WebAuthn fonctionne au niveau du fournisseur d’identité (IdP) dans les environnements fédérés utilisant SAML, OAuth ou OpenID Connect. Votre IdP gère la cérémonie WebAuthn, puis émet des jetons de fédération vers les applications en aval. 

Cela signifie que vous déployez WebAuthn au niveau de l’IdP plutôt que dans chaque application individuelle, ce qui simplifie le déploiement sur l’ensemble des services fédérés.

Comment WebAuthn protège-t-il contre les attaques de l’homme du milieu ?

Le navigateur inclut cryptographiquement l’origine (domaine) dans les données signées par l’authentificateur lors de chaque cérémonie d’authentification. Un attaquant de type homme du milieu ne peut pas relayer une assertion d’authentification vers un domaine différent, car la signature ne sera valide pour aucune origine autre que celle où l’identifiant a été enregistré. 

Cette protection fonctionne au niveau du protocole, indépendamment de TLS ou de la vigilance de l’utilisateur.