MFA, WebAuthn et passkeys : l'authentification forte

Un mot de passe seul ne suffit plus. Le MFA (authentification multi-facteurs) bloque plus de 99% des attaques par credential stuffing. Mais tous les MFA ne se valent pas : le SMS est vulnérable au SIM swapping, le TOTP au phishing. Seuls WebAuthn et les passkeys offrent une résistance native au phishing. Ce guide vous explique ces différences et comment choisir.

Ce que vous allez apprendre

Ce guide vous explique l'authentification forte, du MFA classique aux passkeys. À la fin, vous saurez :

Comprendre les facteurs d'authentification et leurs niveaux de sécurité
Distinguer MFA classique (OTP) et MFA phishing-resistant (WebAuthn)
Maîtriser les concepts WebAuthn, FIDO2 et passkeys
Implémenter le step-up authentication pour les actions sensibles

Prérequis : avoir lu Les bases de l'IAM.

Pourquoi le mot de passe ne suffit plus

Les mots de passe sont la cible #1 des attaquants :

Phishing : l'utilisateur donne son mot de passe à un faux site
Credential stuffing : réutilisation de mots de passe fuités
Brute force : mots de passe faibles = devinables
Keyloggers : malware qui capture les frappes

L'authentification multi-facteurs (MFA) ajoute une couche de protection : même si le mot de passe est volé, l'attaquant a besoin d'un second facteur.

Les trois facteurs d'authentification

La sécurité de l'authentification repose sur ce que l'on appelle les facteurs. Chaque facteur représente une catégorie de preuve d'identité distincte. Plus vous combinez de facteurs différents, plus il devient difficile pour un attaquant de tous les compromettre.

Facteur	Ce que c'est	Exemples
Connaissance	Ce que tu sais	Mot de passe, PIN, question secrète
Possession	Ce que tu as	Téléphone, clé FIDO2, carte à puce
Inhérence	Ce que tu es	Empreinte, visage, iris

MFA = combinaison de facteurs différents

Pour qu'une authentification soit considérée comme véritablement multi-facteurs, elle doit combiner des facteurs de catégories différentes. Combiner deux éléments de la même catégorie (deux mots de passe, par exemple) n'améliore pas significativement la sécurité.

Combinaison	Validité
Mot de passe + PIN	Non, deux fois « connaissance »
Mot de passe + OTP téléphone	Oui, connaissance + possession
Empreinte + visage	Non, deux fois « inhérence »
Mot de passe + clé FIDO2	Oui, connaissance + possession

MFA classique vs MFA phishing-resistant

MFA classique (vulnérable au phishing)

Les méthodes MFA traditionnelles ajoutent une couche de sécurité, mais elles restent vulnérables aux attaques de phishing sophistiquées. Un attaquant peut capturer le second facteur en temps réel et le rejouer immédiatement.

Méthode	Fonctionnement	Vulnérabilité
SMS OTP	Code envoyé par SMS	SIM swap, interception
Email OTP	Code envoyé par email	Compromission email
TOTP (Google Authenticator)	Code temporel (30s)	Phishing en temps réel
Push notification	Validation sur l'app mobile	"Fatigue MFA" (push bombing)

Problème : Un attaquant peut créer un faux site qui demande l'OTP et le rejoue en temps réel vers le vrai site.

MFA phishing-resistant

Les méthodes phishing-resistant ont une propriété fondamentale : le credential est lié cryptographiquement au domaine du site légitime. Même si un attaquant crée un faux site visuellement identique, son domaine diffère et le credential n'est pas utilisable.

Méthode	Fonctionnement	Protection
WebAuthn / FIDO2	Clé cryptographique liée au domaine	L'attaquant ne peut pas rejouer
Passkeys	WebAuthn synchronisé (cloud)	Phishing-resistant + UX simple
Smart card + PIN	Certificat sur carte à puce	Possession physique + PIN

Clé : la vérification du domaine est faite par le navigateur, pas par l'utilisateur. C'est ce déplacement de la responsabilité qui rend la méthode résistante, là où reconnaître une URL trompeuse reste hors de portée de la plupart des gens.

Niveaux d'assurance (NIST 800-63)

Le NIST définit trois Authenticator Assurance Levels (AAL), qui servent de langage commun pour exprimer « à quel point on est sûr de l'identité ». Ils sont décrits dans la publication SP 800-63B, dont la révision 4 est parue en août 2025 et a resserré la définition de l'AAL3.

Le changement à connaître : l'AAL3 ne se résume plus à « deux facteurs dont un matériel ». La révision 4 exige un authentifiant cryptographique, avec une clé privée non exportable stockée dans un environnement d'exécution isolé protégé par le matériel, et résistant au phishing. Conséquence directe : un jeton OTP matériel, bien qu'il soit du matériel, ne suffit pas pour l'AAL3 puisqu'il reste rejouable par un faux site. Au niveau AAL2, une option résistante au phishing doit être proposée sans être imposée.

Niveau	Exigence	Exemple
AAL1	1 facteur, pas de résistance au phishing exigée	Mot de passe seul
AAL2	2 facteurs, une option résistante au phishing doit exister	Mot de passe + OTP
AAL3	2 facteurs, résistance au phishing obligatoire, clé non exportable	Mot de passe + clé FIDO2

Quel niveau pour quel usage ?

Le choix du niveau d'assurance dépend de la sensibilité des données et des actions autorisées. Ne sur-sécurisez pas les accès à faible risque (friction utilisateur inutile), mais n'hésitez pas à exiger AAL3 pour les opérations critiques.

Usage	Niveau recommandé
Lecture de contenu public	AAL1 (ou aucun)
Application SaaS standard	AAL2
Admin systèmes, données sensibles	AAL3
Paiements, signatures légales	AAL3

WebAuthn et FIDO2

Qu'est-ce que FIDO2 ?

FIDO2 est un ensemble de standards pour l'authentification sans mot de passe. Le nom recouvre deux spécifications complémentaires qu'on confond souvent, alors qu'elles interviennent à des endroits différents de la chaîne : WebAuthn est l'interface que le navigateur expose au site web, CTAP est le dialogue entre le navigateur et le périphérique qui détient la clé. Vous n'écrivez jamais de CTAP vous-même, mais c'est lui qui explique pourquoi une clé USB, un téléphone en NFC et un capteur intégré s'utilisent de la même façon côté site.

WebAuthn : API web pour l'authentification (W3C)
CTAP : protocole de communication avec les authenticators (FIDO Alliance)

Comment ça marche

Le mécanisme repose sur la cryptographie asymétrique, en deux temps. Ce qui change tout par rapport à un mot de passe : le serveur ne stocke qu'une clé publique, inutile pour un attaquant. Une fuite de la base de données d'authentification ne donne rien d'exploitable, alors qu'une fuite de hachés de mots de passe se casse hors ligne.

Enregistrement (Registration)

L'utilisateur génère une paire de clés (privée/publique). La clé publique est envoyée au serveur. La clé privée reste sur l'authenticator (clé FIDO2, téléphone).
Authentification (Authentication)

Le serveur envoie un "challenge" (valeur aléatoire). L'authenticator signe le challenge avec la clé privée. Le serveur vérifie la signature avec la clé publique.

Pourquoi c'est phishing-resistant

Le credential est rattaché au domaine du site, ce que la spécification appelle le RP ID (Relying Party ID). À chaque authentification, le navigateur vérifie que l'origine de la page correspond à ce RP ID avant de solliciter l'authenticator.

Enregistrement sur https://banque.exemple.fr → clé rattachée à ce domaine
Faux site https://banque-securite.attaquant.fr → domaine différent → le navigateur ne propose même pas la clé

C'est la différence de nature avec le TOTP : là où l'utilisateur doit reconnaître un faux site, ici la vérification est faite par le navigateur, à partir d'une comparaison de chaînes de caractères qu'aucune ressemblance visuelle ne peut tromper. L'utilisateur n'a rien à comparer, et rien à saisir qui puisse être rejoué.

Types d'authenticators

WebAuthn supporte différents types d'authenticators selon que l'appareil est physiquement séparé (roaming), intégré à votre machine (platform), ou accessible via un mécanisme de pont comme un QR code (hybrid).

Type	Exemple	Portabilité
Roaming	Clé FIDO2 (YubiKey)	Multi-appareils
Platform	Touch ID, Windows Hello	Lié à l'appareil
Hybrid	QR code + téléphone	Cross-device

Passkeys : WebAuthn simplifié

Les passkeys sont des credentials WebAuthn synchronisés entre vos appareils.

Avant les passkeys

Le frein à l'adoption de WebAuthn n'a jamais été technique, mais logistique : la clé privée ne quittant pas l'appareil, chaque appareil devait être enrôlé séparément, et perdre le seul appareil enrôlé signifiait perdre l'accès. C'est ce problème que les passkeys résolvent.

Clé FIDO2 physique → une seule clé, si perdue = problème
Platform authenticator → une clé par appareil → complexe à gérer

Avec les passkeys

La passkey lève la contrainte en autorisant la synchronisation du credential par un gestionnaire, au prix d'un compromis explicite : la clé privée n'est plus strictement non exportable, elle transite chiffrée entre vos appareils. C'est précisément ce compromis qui explique le positionnement en AAL2 plutôt qu'en AAL3 dans le tableau comparatif ci-dessous.

Le credential est synchronisé via iCloud Keychain, Google Password Manager, etc.
Vous vous inscrivez sur un appareil → disponible sur tous vos appareils Apple/Google/Microsoft
UX simplifiée : pas de clé physique à transporter

Fonctionnement technique

Le schéma ci-dessous décrit le trajet d'une passkey entre deux appareils. Regardez surtout où se situe le chiffrement : la clé privée est chiffrée localement avant d'atteindre le fournisseur de synchronisation, qui ne transporte que du contenu qu'il ne peut pas lire. C'est ce point qui distingue une passkey d'un mot de passe stocké dans un gestionnaire, où le fournisseur détient techniquement la capacité de déchiffrement dans certaines configurations.

Synchronisation des passkeys entre appareils via le cloud provider avec chiffrement de bout en bout

Passkeys vs clés FIDO2 physiques

Les deux sont résistants au phishing : le choix ne porte donc pas sur la sécurité de l'authentification elle-même, mais sur le modèle de récupération et sur le niveau d'assurance visé. Lisez la ligne « Niveau de sécurité » en dernier, c'est elle qui tranche : si vous devez atteindre l'AAL3, la clé physique dédiée reste le seul choix, parce que la clé privée y est non exportable par construction.

Aspect	Passkeys	Clé FIDO2 physique
Portabilité	Tous vos appareils (sync)	Une seule clé physique
Récupération	Via le compte cloud	Clé de backup nécessaire
Perte	Récup via cloud	Perdue = perdue
Niveau de sécurité	AAL2-3 (dépend du provider)	AAL3 (hardware dédié)
Usage entreprise	En cours d'adoption	Standard

Récupération de compte : le point faible

La récupération de compte est souvent le maillon faible du MFA.

Risques

Chaque méthode de récupération présente des vulnérabilités spécifiques. Un attaquant ciblera souvent la récupération plutôt que l'authentification principale si c'est le chemin le plus faible.

Méthode de récupération	Risque
Email de récupération	Si l'email est compromis → game over
SMS de récupération	SIM swap
Questions secrètes	Réponses devinables (réseaux sociaux)
Support humain	Ingénierie sociale

Bonnes pratiques

Ces quatre mesures se complètent et s'appliquent ensemble. La deuxième est la plus rentable : enrôler deux authentifiants dès le départ supprime la majorité des demandes de récupération, donc la majorité des occasions d'ingénierie sociale. La quatrième est la plus impopulaire mais la plus efficace contre une prise de contrôle silencieuse, car un délai de plusieurs heures laisse le temps à l'alerte d'atteindre le titulaire légitime.

Codes de récupération : générés à l'enregistrement, stockés hors ligne
Plusieurs authenticators : clé principale + clé de backup
Enrôlement supervisé : vérification d'identité pour les utilisateurs sensibles
Délai de récupération : 24-72h pour détecter les compromissions

Step-up authentication

Le step-up authentication demande une authentification renforcée pour les actions sensibles.

Principe

L'idée est de faire varier l'exigence d'authentification selon l'action, et non selon l'utilisateur ou le moment de la connexion. Une session ouverte le matin ne doit pas suffire à déclencher un virement l'après-midi. Le tableau se lit comme un barème : plus l'action est irréversible, plus la preuve exigée est récente et forte. La dernière ligne mérite attention, désactiver le MFA est souvent la première action d'un attaquant qui vient de prendre la main.

Action	Niveau requis
Consulter son profil	Session normale
Changer son email	Re-authentification
Effectuer un virement	MFA obligatoire
Désactiver le MFA	MFA + confirmation admin

Implémentation avec OIDC

OpenID Connect dispose de deux paramètres faits pour cela. Le premier, acr_values, indique à l'IdP le niveau d'authentification attendu ; le second, max_age, borne l'ancienneté acceptable de la session. Positionner max_age=0 force une ré-authentification même si l'utilisateur vient de se connecter, ce qui est le comportement voulu pour une action sensible. Point de vigilance côté application : la valeur acr doit être revérifiée dans le token retourné, sinon un client peut demander un niveau élevé et se contenter d'un token qui ne le porte pas.

La session initiale a un acr (Authentication Context Class Reference) standard
Pour une action sensible, l'application demande un acr_values plus élevé
L'IdP demande une ré-authentification avec le facteur requis
Un nouveau token est émis avec le nouvel acr

// Demande de step-up
const stepUpUrl = new URL('https://auth.exemple.fr/authorize');
stepUpUrl.searchParams.set('client_id', 'my-app');
stepUpUrl.searchParams.set('response_type', 'code');
stepUpUrl.searchParams.set('scope', 'openid');
stepUpUrl.searchParams.set('acr_values', 'urn:example:mfa'); // Exige MFA
stepUpUrl.searchParams.set('max_age', '0'); // Force ré-auth

MFA fatigue et push bombing

Le risque

Un attaquant qui a le mot de passe peut spammer les push notifications :

L'attaquant tente de se connecter → push envoyé
L'utilisateur refuse
L'attaquant réessaie → nouveau push
L'utilisateur fatigué finit par accepter (ou par erreur)

Mitigations

Les deux premières mitigations transforment une validation passive en action qui demande de regarder l'écran d'origine : l'utilisateur ne peut plus approuver machinalement. Les deux suivantes agissent sur le volume et la détection. Aucune ne supprime la vulnérabilité de fond, qui tient au format même de la notification push. La solution définitive reste de remplacer le push par un facteur résistant au phishing.

Mitigation	Description
Number matching	L'utilisateur doit entrer un code affiché sur le site
Contexte géographique	Afficher la localisation de la tentative
Rate limiting	Limiter le nombre de push par heure
Alerte anomalie	Notifier plusieurs refus consécutifs

Configuration Keycloak MFA

Activer TOTP

Dans Keycloak, activer un second facteur se fait toujours en deux endroits distincts, et c'est la source d'erreur la plus fréquente : une required action décide de ce que l'utilisateur devra configurer, un flow d'authentification décide de ce qui lui sera demandé à la connexion. Activer seulement la required action donne des utilisateurs qui enregistrent un TOTP jamais réclamé ensuite.

Realm Settings → Authentication → Required Actions

Activer "Configure OTP"
Authentication → Flows → Browser

Ajouter une étape "OTP Form" après le login
Première connexion utilisateur

L'utilisateur scanne un QR code pour enregistrer un TOTP

Activer WebAuthn

La logique est identique à celle du TOTP, avec une étape supplémentaire : la WebAuthn Policy du realm. C'est elle qui détermine si Keycloak exige une attestation du fabricant de la clé, quels algorithmes de signature sont acceptés et si le résident key est requis. Commencez avec une politique permissive et resserrez ensuite, une attestation exigée d'emblée rejette silencieusement des clés parfaitement valides.

Testez impérativement le parcours complet sur un compte de test avant de rendre l'étape obligatoire. WebAuthn ne fonctionne que sur une origine HTTPS ou sur localhost : sur une instance de développement servie en HTTP, l'enregistrement échouera sans message explicite.

Realm Settings → Authentication → WebAuthn Policy

Configurer les paramètres (attestation, algorithmes)
Authentication → Required Actions

Activer "WebAuthn Register"
Authentication → Flows → Browser

Ajouter "WebAuthn Authenticator" comme alternative ou requis

Erreurs fréquentes

Ces quatre erreurs se retrouvent dans presque tous les déploiements MFA menés sans revue. Les deux premières ont la même racine : on soigne le chemin d'authentification nominal et on laisse le chemin de secours au niveau d'avant. Un attaquant, lui, prend toujours le chemin le moins protégé.

Erreur	Conséquence	Solution
Récupération par SMS seul	Bypass MFA via SIM swap	Codes de récupération hors ligne
Pas de backup authenticator	Lockout si perte de téléphone	Exiger 2 authenticators
TOTP présenté comme "secure"	Faux sentiment de sécurité	Éduquer sur le phishing TOTP
MFA optionnel pour les admins	Compte admin = cible facile	MFA obligatoire (AAL3)

À retenir

Références

Prochaines étapes

RBAC, ABAC et politiques Modélisez les permissions après l'authentification.

Sécurité opérationnelle IAM Opérez un système d'identité en production.

Déployer Keycloak Configurer le MFA avec Keycloak.

Comprendre authentik MFA conditionnel via flows et stages dans authentik.