FIDO2 : WebAuthn, Passkeys et Sécurité Expliqués en Détail (FR)

FIDO2 comprend deux normes d'authentification à clé publique : l'API d'authentification web (WebAuthn) du World Wide Web Consortium et le protocole FIDO Client to Authenticator Protocol (CTAP) de la FIDO Alliance. Ensemble, elles permettent à une partie de confiance d'enregistrer et d'utiliser une information d'identification cryptographique sans stocker un secret partagé réutilisable comme un mot de passe.

FIDO2 peut offrir une authentification résistante au phishing et aux attaques par rejeu lorsqu'elle est correctement implémentée et validée. Elle ne prouve pas l'identité légale d'une personne, ne décide pas qui doit être autorisé à s'inscrire, ne sécurise pas une session serveur compromise, ni ne répare un processus de récupération de compte faible. Ce sont des contrôles adjacents qui doivent être conçus autour de la cérémonie d'authentification.

Points clés à retenir

• FIDO2 est WebAuthn plus CTAP. WebAuthn connecte un site web ou une application au client ; CTAP connecte la plateforme cliente à un authentificateur itinérant.
• La clé privée reste avec l'authentificateur. La partie de confiance stocke une clé publique et vérifie les signatures sur des défis frais et un contexte délimité.
• La liaison de domaine crée une résistance au phishing. Une information d'identification enregistrée pour un identifiant de partie de confiance ne peut pas être simplement rejouée sur un domaine sans rapport d'un attaquant.
• Les passkeys sont des informations d'identification FIDO. Elles peuvent être liées à un appareil ou synchronisées entre les appareils d'un fournisseur, créant différents compromis en termes d'assurance, de récupération et de portabilité.
• La récupération fait partie du modèle de sécurité. Une connexion FIDO2 forte peut être contournée si les chemins de récupération par e-mail, support ou identité peuvent remplacer l'information d'identification par des preuves plus faibles.

Qu'est-ce que FIDO2 ?

L'aperçu des spécifications de la FIDO Alliance définit FIDO2 comme la combinaison de la spécification W3C WebAuthn et des protocoles FIDO Client to Authenticator. Les normes divisent le système en rôles coopératifs :

• Partie de confiance : le site web ou le service qui enregistre les informations d'identification et vérifie les assertions d'authentification.
• Client : généralement le navigateur ou le composant du système d'exploitation qui implémente WebAuthn et gère la cérémonie.
• Authentificateur : un composant de plateforme ou un périphérique externe qui crée et utilise la clé d'information d'identification.
• Utilisateur : la personne qui consent à l'enregistrement ou à l'authentification et qui peut vérifier localement avec un code PIN, un mot de passe ou une biométrie.

La spécification W3C WebAuthn Level 3 définit une API web pour la création et l'utilisation d'informations d'identification à clé publique délimitées à une partie de confiance. Les scripts ne reçoivent jamais la clé privée d'information d'identification. Ils reçoivent des données structurées et des preuves cryptographiques produites via l'authentificateur et le client.

FIDO2, WebAuthn, CTAP, U2F et passkeys comparés

Terme	Signification pratique	Principale limite
FIDO2	Les normes WebAuthn et CTAP utilisées ensemble	Famille de normes complète, pas un seul appel API
WebAuthn	API de navigateur ou de client et modèle de données de partie de confiance pour les informations d'identification à clé publique	Connecte la partie de confiance au client
CTAP2	Protocole entre la plateforme cliente et un authentificateur itinérant	Transporte la communication de l'authentificateur externe sur des supports tels que l'USB, le NFC et le BLE
U2F / CTAP1	Ancien protocole FIDO communément associé aux clés de sécurité de deuxième facteur	Plus limité que les capacités FIDO2 modernes
Passkey	Une information d'identification FIDO découvrable conçue pour la connexion sans mot de passe	Peut être synchronisée ou liée à un appareil
Clé de sécurité	Un authentificateur matériel itinérant connecté par USB, NFC ou un autre support pris en charge	Une forme d'authentificateur possible
Authentificateur de plateforme	Authentificateur intégré à un appareil ou un système d'exploitation	Souvent activé avec un code PIN ou une biométrie locale

« Sans mot de passe » décrit le parcours utilisateur, pas tous les déploiements possibles. Un service peut utiliser WebAuthn comme deuxième facteur après un mot de passe, comme information d'identification multifactorielle principale, ou aux côtés d'autres authentificateurs. La partie de confiance doit décider quelles caractéristiques et indicateurs d'information d'identification répondent à l'assurance de l'action protégée.

Fonctionnement de l'enregistrement FIDO2

L'enregistrement, également appelé création d'information d'identification, lie une nouvelle information d'identification à clé publique à un compte auprès de la partie de confiance.

1. Le serveur crée des options d'enregistrement

La partie de confiance génère un défi frais et imprévisible et envoie des options de création d'informations d'identification à clé publique au client. Les options identifient la partie de confiance, le compte utilisateur, les algorithmes acceptés, les préférences de l'authentificateur, la préférence d'attestation et les identifiants d'informations d'identification existants exclus le cas échéant.

Les défis doivent être à usage unique, de courte durée, liés à la session et à l'utilisateur corrects, et stockés ou vérifiables par le serveur. Un défi généré uniquement dans le navigateur ne peut pas protéger la cérémonie du serveur.

2. Le client invoque WebAuthn

L'application appelle navigator.credentials.create() avec les options de clé publique. Le navigateur vérifie l'origine et le contexte de sécurité, puis demande à un authentificateur disponible de créer une information d'identification.

3. L'authentificateur obtient le consentement de l'utilisateur

L'authentificateur exige la présence de l'utilisateur et, si demandé et pris en charge, la vérification de l'utilisateur. La présence de l'utilisateur peut être un toucher ou une action explicite. La vérification de l'utilisateur signifie que l'authentificateur vérifie localement l'utilisateur via un code PIN, un secret d'appareil, une biométrie ou une autre méthode prise en charge.

Une biométrie locale déverrouille normalement l'utilisation de l'information d'identification ; le modèle biométrique n'est pas envoyé au site web comme secret d'authentification.

4. L'authentificateur crée une paire de clés

L'authentificateur crée une paire de clés d'information d'identification délimitée à la partie de confiance. La clé privée reste protégée par l'authentificateur ou son infrastructure de synchronisation. L'information d'identification résultante contient la clé publique, l'identifiant d'information d'identification, les données de l'authentificateur, les données du client et les informations d'attestation selon le format sélectionné.

5. Le serveur valide et stocke l'information d'identification

La partie de confiance valide la cérémonie avant de stocker quoi que ce soit. Les vérifications comprennent :

• le défi attendu ;
• l'origine attendue ;
• le hachage correct de l'identifiant de la partie de confiance ;
• l'état inter-origines attendu et topOrigin lorsque la cérémonie est intégrée ;
• les indicateurs de présence de l'utilisateur et de vérification de l'utilisateur selon la politique ;
• l'algorithme et les paramètres de clé acceptés ;
• la structure d'attestation et la politique de confiance si l'attestation est demandée ;
• l'unicité et l'association avec le compte utilisateur correct.

Le serveur stocke l'identifiant d'information d'identification, la clé publique, la liaison de compte, le compteur de signature ou l'état applicable, les transports ou les métadonnées utiles, et les informations sur le cycle de vie de l'information d'identification. Il n'a jamais besoin de la clé privée.

Fonctionnement de l'authentification FIDO2

L'authentification prouve le contrôle d'une information d'identification précédemment enregistrée.

1. Le serveur crée des options de requête

La partie de confiance génère un nouveau défi et envoie des options d'assertion. Elle peut inclure une liste d'autorisation d'identifiants d'informations d'identification ou utiliser des informations d'identification découvrables afin que l'authentificateur puisse identifier le compte.

2. Le client demande une assertion

L'application appelle navigator.credentials.get(). Le navigateur et l'authentificateur sélectionnent une information d'identification appropriée et obtiennent la présence de l'utilisateur ou la vérification locale de l'utilisateur requise.

3. L'authentificateur signe les données de la cérémonie

L'authentificateur signe le contexte du défi frais et les données de l'authentificateur à l'aide de la clé privée de l'information d'identification. Étant donné que l'information d'identification est délimitée à la partie de confiance, une origine de phishing sans rapport ne peut pas demander à l'authentificateur de produire une assertion valide pour le service réel.

4. Le serveur vérifie l'assertion

La partie de confiance vérifie le défi attendu, l'origine, le hachage de la partie de confiance, la signature avec la clé publique stockée, les indicateurs requis, l'information d'identification autorisée, la liaison de l'utilisateur et le compteur ou l'état de sauvegarde pertinent. Ce n'est qu'alors qu'il doit créer ou élever une session d'application.

Chaque assertion prouve le contrôle à un moment donné. La création de session, la protection des jetons, la réauthentification, l'autorisation de transaction, la déconnexion et la révocation restent des responsabilités d'application distinctes.

Pourquoi FIDO2 est résistant au phishing

Les mots de passe et les codes à usage unique peuvent être saisis sur un site imposteur, qui peut les transmettre au service réel. FIDO2 utilise une information d'identification délimitée à la partie de confiance et lie cryptographiquement l'assertion au contexte de vérificateur attendu.

Les exigences d'authentificateur NIST SP 800-63B-4 décrivent WebAuthn comme résistant au phishing grâce à la liaison du nom du vérificateur. La sortie de l'authentificateur est liée au nom de domaine authentifié au lieu de dépendre de l'utilisateur qui remarque une page trompeuse.

La résistance au phishing a des limites :

• Elle n'arrête pas les logiciels malveillants ou un attaquant qui contrôle déjà une session authentifiée.
• Elle n'empêche pas un utilisateur d'approuver une transaction malveillante au sein du service authentique.
• Elle ne sécurise pas un chemin de récupération de compte qui peut remplacer l'information d'identification.
• Elle ne prouve pas que la personne contrôlant l'authentificateur est la personne réelle qu'une organisation avait l'intention d'inscrire.

Résistance au rejeu et gestion des défis

Une assertion enregistrée ne devrait pas fonctionner dans une cérémonie ultérieure car chaque requête utilise un défi frais. Le NIST décrit les authentificateurs cryptographiques qui intègrent des nonces ou des défis comme résistants au rejeu.

Des erreurs d'implémentation peuvent supprimer cette propriété. Les échecs courants incluent des défis prévisibles, la réutilisation de défis, l'acceptation d'un défi pour le mauvais compte, le non-respect de l'expiration, ou la validation uniquement de la signature tout en ignorant l'origine et le contexte de la partie de confiance.

Le serveur doit marquer un défi consommé de manière atomique. Si des requêtes parallèles sont en concurrence, une seule cérémonie réussie doit pouvoir utiliser ce défi.

Présence de l'utilisateur et vérification de l'utilisateur

WebAuthn distingue :

• Présence de l'utilisateur (UP) : l'utilisateur a effectué une interaction indiquant sa participation.
• Vérification de l'utilisateur (UV) : l'authentificateur a vérifié localement l'utilisateur via un facteur d'activation tel qu'un code PIN ou une biométrie.

La seule présence n'est pas une authentification multifactorielle. Un service protégeant une action à risque plus élevé peut exiger l'indicateur UV et rejeter les assertions qui ne montrent que la présence. Les exigences doivent indiquer les valeurs d'indicateur attendues plutôt que de se fier à une étiquette d'interface telle que « Utiliser Face ID ».

La qualité de la vérification locale varie également selon l'authentificateur. La partie de confiance peut avoir une visibilité limitée sur l'implémentation exacte de la biométrie ou du code PIN pour les authentificateurs fournis par l'utilisateur, de sorte que la politique doit être proportionnée à la transaction et à la population de déploiement.

Authentificateurs de plateforme, itinérants et inter-appareils

Authentificateurs de plateforme

Ceux-ci sont intégrés à un téléphone, un ordinateur portable ou un système d'exploitation. Ils peuvent offrir un parcours court en utilisant la méthode de déverrouillage locale de l'appareil. Le compromis est la dépendance à la récupération de compte de la plateforme, à la sécurité de l'appareil et au comportement de synchronisation.

Authentificateurs itinérants

Les clés de sécurité externes peuvent être transportées entre les appareils et connectées via des supports pris en charge. Elles sont utiles pour les cas d'utilisation en entreprise, administratifs ou de haute assurance, en particulier lorsque la non-exportabilité des informations d'identification et l'émission gérée sont importantes.

Authentification inter-appareils

Les flux hybrides peuvent utiliser un téléphone à proximité pour authentifier une session sur un autre appareil. Les mécanismes de transfert et de proximité améliorent la convivialité mais ajoutent des détails d'interface utilisateur et de modèle de menace qui doivent être testés plutôt que traités comme identiques à l'authentification sur le même appareil.

Prend en charge plusieurs informations d'identification par compte. Les utilisateurs remplacent les téléphones, perdent les clés de sécurité, utilisent des appareils professionnels et personnels, et ont besoin d'un moyen sûr de nommer, d'inspecter et de supprimer les informations d'identification.

Passkeys liées à l'appareil et synchronisées

Une passkey est une information d'identification FIDO conçue pour la connexion sans mot de passe. Les passkeys peuvent être :

• Liées à l'appareil : la clé privée d'information d'identification reste liée à un seul authentificateur ou appareil géré.
• Synchronisées : le matériel d'information d'identification est chiffré et synchronisé via le système d'un fournisseur pour être utilisé sur des appareils éligibles.

Les passkeys synchronisées améliorent la disponibilité et la récupération, tandis que les informations d'identification liées à l'appareil peuvent offrir une non-exportabilité plus forte. Les directives NIST SP 800-63B-4 pour les authentificateurs synchronisables autorisent les authentificateurs synchronisables dans des contextes jusqu'au niveau d'assurance d'authentification 2 lorsque ses exigences sont satisfaites, mais la synchronisation est en conflit avec la non-exportabilité requise au niveau 3.

N'inférez pas l'assurance du mot « passkey ». Évaluez si les informations d'identification sont sauvegardées, éligibles à la sauvegarde, partagées, gérées, liées à l'appareil, attestées et activées avec la vérification de l'utilisateur conformément à la politique de la partie de confiance.

Attestation et confiance de l'authentificateur

L'attestation peut fournir des preuves sur la provenance ou les propriétés d'un authentificateur lors de l'enregistrement. Elle n'est pas identique à la signature d'authentification et n'identifie pas l'utilisateur humain.

Les services grand public minimisent souvent la collecte d'attestations pour des raisons de confidentialité et de compatibilité avec l'écosystème. Les déploiements en entreprise gérés peuvent exiger des modèles d'authentification ou une certification spécifiques. La décision doit répondre à une question de modèle de menace plutôt que de collecter par défaut des preuves d'identification de l'appareil.

Si l'attestation est utilisée :

• définir les formats acceptés et les ancres de confiance ;
• valider correctement les chemins de certificat et les déclarations ;
• spécifier la mise à jour des métadonnées et la gestion de la révocation ;
• planifier les authentificateurs sans attestation fiable ;
• documenter les conséquences sur la confidentialité et la rétention ;
• tester le remplacement lorsqu'un modèle accepté change de statut.

FIDO2 ne remplace pas la vérification d'identité

FIDO2 prouve le contrôle d'une information d'identification enregistrée auprès d'une partie de confiance. Il n'établit pas le nom légal, l'âge, l'adresse, le statut réglementaire ou l'unicité réelle de la personne qui l'enregistre.

Cette distinction crée trois modèles courants :

1. Enregistrement pseudonyme : le service a besoin d'un compte sécurisé mais pas d'une identité réelle vérifiée.
2. Enregistrement lié à l'identité : la vérification d'identité a lieu en premier, puis une information d'identification FIDO est liée au compte vérifié.
3. Élévation ou récupération : le service revérifie l'identité ou utilise d'autres preuves solides avant de permettre le remplacement d'un authentificateur perdu.

La liaison doit être explicite. Enregistrez quel compte et quel état de vérification existaient lorsque l'information d'identification a été ajoutée, quelle session l'a autorisée, et si un risque ultérieur devrait déclencher une réauthentification ou un rafraîchissement d'identité.

Récupération de compte et cycle de vie des informations d'identification

La récupération est l'endroit où de nombreux déploiements résistants au phishing se dégradent. Si un utilisateur peut remplacer chaque information d'identification FIDO à l'aide d'un lien envoyé par e-mail ou de questions de support faibles, un attaquant ciblera plutôt ce chemin.

Un cycle de vie complet couvre :

• l'ajout d'un deuxième authentificateur ;
• la nomination et la visualisation des informations d'identification enregistrées ;
• la perte d'appareil et la suspicion de compromission ;
• la révocation d'une information d'identification sans détruire le compte ;
• la récupération avec des codes, un autre authentificateur, un support géré ou une vérification d'identité ;
• la notification de l'utilisateur par un canal indépendant ;
• le report ou la limitation des actions à haut risque après récupération ;
• l'enregistrement de qui a modifié l'ensemble des informations d'identification et pourquoi ;
• la fermeture des sessions créées avant la déclaration de compromission.

L'assurance de la récupération doit correspondre à la conséquence du remplacement de l'authentificateur. Un compte communautaire à faible risque et un administrateur qui peut déplacer des fonds n'ont pas besoin du même chemin.

Comment évaluer un déploiement FIDO2

Validation du protocole

Testez la génération et l'expiration des défis, la validation exacte de l'origine, les règles d'identifiant de partie de confiance, la vérification de signature, les algorithmes pris en charge, la politique UP et UV, l'association d'informations d'identification, les compteurs, les indicateurs de sauvegarde et la gestion des erreurs. Préférez une bibliothèque de serveur maintenue à l'analyse binaire écrite à la main, tout en comprenant ce qu'elle valide.

Couverture de l'authentificateur

Testez les authentificateurs de plateforme et itinérants sur les navigateurs, systèmes d'exploitation, appareils, transports, politiques d'entreprise et paramètres d'accessibilité pris en charge. Incluez la création d'informations d'identification, la connexion, l'interface utilisateur conditionnelle, l'utilisation inter-appareils et le remplacement d'appareil.

Sécurité du compte et de la session

Examinez qui peut ajouter une information d'identification, si une authentification récente est requise, comment les sessions sont élevées, quand la réauthentification a lieu et comment les changements d'informations d'identification affectent les sessions existantes.

Récupération et support

Simulez la perte, les appareils volés, les e-mails compromis, le changement de carte SIM, l'usurpation de support et l'accès malveillant au domicile ou au lieu de travail. Mesurez à la fois la résistance de l'attaquant et l'achèvement par l'utilisateur authentique.

Confidentialité et observabilité

Minimisez l'attestation et les données de l'appareil à ce dont la politique a besoin. Évitez d'utiliser des identifiants d'informations d'identification stables entre les parties de confiance ; la délimitation de WebAuthn est conçue pour empêcher cela. Enregistrez les raisons et les résultats de la cérémonie sans divulguer de données client sensibles.

Erreurs courantes d'implémentation de FIDO2

Vérifier la signature mais pas le contexte

Une signature valide est insuffisante si le serveur ne parvient pas à vérifier exactement le défi, l'origine, l'identifiant de la partie de confiance, les indicateurs et la liaison de compte.

Appeler chaque passkey multifactorielle

Le serveur doit vérifier si la vérification de l'utilisateur a eu lieu et si les caractéristiques de l'information d'identification répondent à la politique. La seule présence de l'utilisateur n'est pas la même chose que la vérification locale de l'utilisateur.

Autoriser l'ajout silencieux d'informations d'identification

L'ajout d'un nouvel authentificateur modifie la sécurité du compte. Exigez une authentification récente appropriée ou une cérémonie de récupération, informez l'utilisateur et enregistrez l'événement.

Ne prendre en charge qu'une seule information d'identification

Les comptes à une seule information d'identification créent une récupération fragile et encouragent des solutions de repli plus faibles. Autorisez plusieurs authentificateurs avec une gestion et une révocation claires.

Laisser le mot de passe comme solution de repli égale

Si un mot de passe peut toujours contourner le chemin FIDO, la résistance au phishing peut n'exister que sur le bouton préféré. Restreignez ou supprimez les chemins plus faibles en fonction du risque et de l'étape de migration.

Ignorer les sessions serveur

FIDO2 authentifie la cérémonie de connexion. Protégez les cookies et les jetons, faites pivoter les sessions après l'authentification, exigez une élévation pour les actions sensibles et révoquez les sessions compromises.

Une liste de contrôle de déploiement

Avant le lancement, confirmez que :

• les défis sont imprévisibles, à usage unique, de courte durée et liés à la session correcte ;
• l'origine, l'identifiant de la partie de confiance, la signature, l'algorithme, les indicateurs et la propriété de l'information d'identification sont validés ;
• les exigences UP et UV sont explicites pour chaque action protégée ;
• les cas de plateforme, itinérance, synchronisation, liaison à l'appareil et inter-appareils sont testés tels que pris en charge ;
• les utilisateurs peuvent enregistrer plusieurs informations d'identification et les nommer, les inspecter et les révoquer en toute sécurité ;
• l'ajout d'informations d'identification et la récupération nécessitent une assurance proportionnée et génèrent des notifications ;
• la collecte d'attestations a une politique de confiance, de confidentialité et de métadonnées définie ;
• les solutions de repli par mot de passe, code à usage unique, support et récupération d'identité sont modélisées en fonction des menaces ;
• les sessions authentifiées et l'autorisation de transaction sont protégées séparément ;
• les bibliothèques de protocole, la prise en charge des navigateurs, les dépréciations et les événements de sécurité ont des propriétaires.

Où Didit s'intègre à FIDO2

FIDO2 gère l'authentification après l'enregistrement d'une information d'identification. Didit peut prendre en charge la décision d'identité adjacente grâce à la Vérification d'identité, la Détection de vivacité et l'Authentification biométrique. Le prix publié de l'authentification biométrique est de 0,10 $ par vérification.

Les équipes peuvent consulter les tarifs actuels des modules sur la page de tarification. Il ne faut pas supposer que ces produits implémentent FIDO2 à partir de cette description : le point architectural est que la vérification d'identité, les vérifications biométriques, l'authentification des informations d'identification FIDO, la récupération de compte et l'autorisation d'application sont des décisions de confiance différentes.

Questions fréquemment posées

Que signifie FIDO2 ?

FIDO signifie Fast Identity Online. FIDO2 est la famille de normes combinant W3C WebAuthn avec FIDO Alliance CTAP pour l'authentification à clé publique.

FIDO2 est-il identique à WebAuthn ?

Non. WebAuthn définit l'API et le modèle de données de la partie de confiance et du client. FIDO2 inclut WebAuthn plus CTAP, qui connecte la plateforme cliente aux authentificateurs itinérants.

Les passkeys sont-elles des informations d'identification FIDO2 ?

Oui. Les passkeys sont des informations d'identification FIDO découvrables conçues pour la connexion sans mot de passe. Elles peuvent être synchronisées entre les appareils éligibles ou rester liées à l'appareil.

FIDO2 est-il résistant au phishing ?

L'authentification FIDO2 correctement validée est résistante au phishing car l'information d'identification est délimitée à la partie de confiance et l'assertion est liée à ce contexte de vérificateur. Une récupération faible ou une session déjà compromise peut toujours contourner la protection prévue.

FIDO2 utilise-t-il la biométrie ?

Il peut utiliser une biométrie locale pour activer un authentificateur et définir la vérification de l'utilisateur. La partie de confiance reçoit normalement le résultat et l'assertion cryptographique, pas le modèle biométrique.

FIDO2 vérifie-t-il l'identité d'une personne ?

Non. Il vérifie le contrôle d'une information d'identification enregistrée. La vérification d'identité réelle est une décision d'enregistrement ou de récupération distincte lorsque le service l'exige.

Que se passe-t-il lorsqu'un utilisateur perd tous ses authentificateurs ?

Le service a besoin d'une politique de récupération proportionnée au risque du compte. Les options peuvent inclure un autre authentificateur enregistré, des codes de récupération, une récupération administrative gérée ou une nouvelle vérification d'identité, avec notification et restrictions post-récupération.

Références principales

• Spécifications d'authentification utilisateur de la FIDO Alliance
• W3C Web Authentication Level 3 Candidate Recommendation Snapshot
• FIDO Alliance CTAP 2.3 Proposed Standard
• NIST SP 800-63B-4 : Gestion de l'authentification et des authentificateurs
• Exigences d'authentificateur NIST SP 800-63B-4

FIDO2 remplace les secrets de vérificateur réutilisables par des informations d'identification à clé publique délimitées et des cérémonies cryptographiques fraîches. Sa valeur ne subsiste que lorsque la partie de confiance valide le contexte complet, gère le cycle de vie des informations d'identification, protège les sessions et les actions sensibles, et accorde à la récupération la même attention de sécurité qu'à la connexion.