L’authentification sans mot de passe vérifie l’identité d’un utilisateur sans exiger de mot de passe. Au lieu de secrets partagés, elle s’appuie sur ce que vous possédez (un appareil ou un code à usage unique) ou ce qui vous caractérise (empreintes digitales, reconnaissance faciale).

Pour les développeurs, l’authentification sans mot de passe simplifie les flux de connexion et contribue à réduire la surface d’attaque liée au stockage et à la gestion des mots de passe. Elle supprime la charge opérationnelle associée à la réinitialisation des mots de passe, au verrouillage des comptes et à la surveillance des brèches. Les méthodes sans mot de passe améliorent également l’expérience utilisateur en réduisant les mauvaises pratiques en matière de mots de passe et les demandes de support.

Selon le rapport Verizon Data Breach Investigations Report (DBIR) 2025, l’utilisation frauduleuse d’identifiants reste le principal vecteur d’accès initial dans les brèches, représentant 22 % des cas.

Les implémentations modernes utilisent des standards tels que FIDO2, WebAuthn et la cryptographie basée sur l’appareil pour offrir une authentification sécurisée et conviviale qui élimine le besoin de recourir aux mots de passe.

Les mots de passe créent des failles de sécurité et des surcharges opérationnelles qui affectent les utilisateurs et les équipes de développement. Ils exigent un stockage sécurisé à l’aide d’algorithmes de hachage adaptatifs (Argon2, bcrypt, PBKDF2), une surveillance des brèches et des politiques de verrouillage de comptes. Les demandes de support liées aux mots de passe augmentent souvent le volume des tickets du service d’assistance.

Les utilisateurs réutilisent souvent leurs mots de passe sur plusieurs sites. Or, cette réutilisation permet des attaques de credential stuffing, où les identifiants compromis lors d’une brèche sont réutilisés pour accéder à d’autres services.

L’authentification sans mot de passe répond à trois problèmes fondamentaux :

• Sécurité : les mots de passe sont vulnérables au phishing, au credential stuffing, aux attaques par relecture et aux brèches de bases de données. Les acteurs malveillants peuvent voler les mots de passe par social engineering, malwares ou compromission de bases de données. Les méthodes sans mot de passe, en particulier celles qui utilisent la cryptographie asymétrique comme WebAuthn, contribuent à éliminer ces vecteurs d’attaque liés aux secrets partagés en supprimant le besoin d’établir ces mêmes secrets. Avec WebAuthn, les clés privées ne sont jamais transmises à partir de l’appareil, ce qui rend impossible le vol d’identifiants à distance.
• Expérience utilisateur : les réinitialisations de mots de passe entraînent des abandons lors de parcours utilisateurs critiques et peuvent générer un grand nombre de demandes de support. Les utilisateurs oublient souvent leur mot de passe, ce qui entraîne des échecs de connexion et une augmentation des demandes de support. L’authentification sans mot de passe permet aux utilisateurs de s’authentifier avec des fonctionnalités familières de l’appareil (reconnaissance faciale, empreintes digitales) ou des méthodes de vérification simples (codes à usage unique), ce qui réduit les frictions et améliore les taux de conversion.
• Charge de travail du développeur : la gestion du stockage des mots de passe nécessite l’implémentation d’un hachage sécurisé avec des facteurs appropriés, la génération de valeurs salt et la surveillance des brèches. Les flux de réinitialisation des mots de passe nécessitent une infrastructure e‑mail, une gestion des tokens et une gestion de l’expiration. Les politiques de verrouillage de comptes exigent un suivi des tentatives infructueuses et l’implémentation de mécanismes de déverrouillage. L’authentification sans mot de passe élimine ou réduit considérablement ces exigences d’implémentation, ce qui permet aux développeurs de se concentrer sur les fonctionnalités essentielles de l’application.

L’authentification sans mot de passe suit un modèle cohérent :

1. Vérification de l’identité : l’utilisateur prouve qu’il contrôle un facteur de possession (par exemple un appareil, une clé physique, un e‑mail ou un téléphone) ou un facteur d’inhérence (par exemple une donnée biométrique).
2. Validation côté serveur : le serveur d’authentification valide cette preuve au moyen de signatures cryptographiques (méthodes asymétriques) ou de codes à durée limitée (méthodes OTP).
3. Émission de tokens : une fois l’authentification de l’utilisateur terminée, le client échange le code d’autorisation au niveau de l’endpoint de token à l’aide de PKCE. L’endpoint de token renvoie un token d’identification (contenant les revendications d’identité) et un token d’accès (pour l’autorisation de l’API). Les tokens ne sont jamais renvoyés par le canal frontal.
4. Établissement de session : l’application établit une session à l’aide de cookies HttpOnly sécurisés ou d’un stockage de session côté serveur.

Les méthodes asymétriques (WebAuthn, passkeys) protègent les identifiants contre l’exfiltration à distance. Les OTP par e‑mail, les codes SMS et le TOTP exposent des secrets que les pirates peuvent intercepter ou compromettre.

WebAuthn (FIDO2)

WebAuthn permet aux navigateurs et aux appareils de créer des paires de clés asymétriques. La clé privée reste sur l’appareil et n’est jamais transmise. Le serveur ne stocke que la clé publique. Lors de l’authentification, le serveur émet un challenge (demande) et l’appareil le signe avec la clé privée, prouvant ainsi qu’il est en possession de la clé sans exposer cette dernière.

WebAuthn offre de solides garanties cryptographiques avec une intégration de plateforme native pour les navigateurs et systèmes d’exploitation modernes. Les utilisateurs s’authentifient au moyen de capteurs biométriques intégrés ou de clés de sécurité matérielles.

Passkeys

Les passkeys, ou clés d’accès, sont des identifiants WebAuthn qui se synchronisent à travers l’écosystème d’appareils d’un utilisateur à l’aide de gestionnaires d’identifiants fournis par la plateforme. Les utilisateurs s’authentifient à l’aide de données biométriques ou d’un code PIN et peuvent s’authentifier sur plusieurs appareils en scannant un code QR.

Les passkeys maintiennent la sécurité cryptographique de WebAuthn tout en améliorant la convivialité grâce à la synchronisation. Bien que le mécanisme de synchronisation élargisse la surface d’attaque si le compte de l’utilisateur est compromis, les protections cryptographiques sous-jacentes restent intactes.

Mots de passe à usage unique (OTP)

• OTP par e‑mail : les utilisateurs reçoivent les codes de vérification par e‑mail. La sécurité dépend de la sécurité du compte de messagerie de l’utilisateur. Convient mieux aux applications grand public qui donnent la priorité à la conversion des inscriptions ou aux flux de récupération de comptes.
• OTP par SMS : vulnérables aux attaques par portage de carte SIM et à l’interception de messages. Évitez d’utiliser les OTP par SMS dans les scénarios à niveau d’assurance élevé, à moins qu’il n’y ait pas d’autre solution.
• Mots de passe à usage unique à durée limitée (TOTP) : les authentificateurs génèrent des codes localement, ce qui élimine le risque d’interception. Cependant, le TOTP reste vulnérable aux attaques de phishing ou de relais en temps réel (Man-in-the-Middle). Un attaquant qui convainc un utilisateur de saisir son code TOTP actuel sur un site malveillant peut immédiatement relayer ce code au service légitime dans la fenêtre de validité d’environ 30 secondes. Le TOTP répond aux exigences du MFA dans certains scénarios de conformité, mais il n’est pas résistant au phishing.

Magic links

Les utilisateurs reçoivent des liens d’authentification à usage unique par e‑mail. L’utilisateur doit cliquer sur le lien pour terminer l’authentification. Les magic links simplifient l’expérience utilisateur, mais dépendent de la sécurité de l’e‑mail et offrent une protection limitée contre le phishing. Ils conviennent mieux aux applications grand public avec des limites de temps strictes (souvent de 5 à 15 minutes) et des contraintes d’utilisation unique.

Notifications push

Les authentificateurs envoient des messages d’approbation aux appareils enregistrés. Les utilisateurs sélectionnent « Approuver » ou « Refuser » au lieu de saisir un code. L’approbation en mode push offre une meilleure expérience utilisateur que TOTP, mais reste vulnérable aux attaques exploitant la fatigue MFA, où les attaquants envoient des demandes en mode push en espérant que les utilisateurs les approuveront accidentellement. Convient mieux aux environnements d’entreprise qui exigent une formation des utilisateurs et une détection des anomalies.

L’authentification sans mot de passe englobe plusieurs méthodes, les passkeys représentent une implémentation spécifique et le MFA décrit une exigence de sécurité. Le tableau suivant montre comment ces concepts se recoupent :

Concept	Définition	Exemple
Authentification sans mot de passe	Toute méthode d’authentification sans mot de passe	WebAuthn, passkeys, magic links, TOTP, OTP par e‑mail
Passkeys	Identifiants WebAuthn synchronisés avec vérification intégrée de l’utilisateur	Authentification par reconnaissance faciale ou empreinte digitale
MFA	Mécanisme impliquant au moins deux facteurs indépendants appartenant à des catégories différentes	Mot de passe + TOTP, ou passkey seule (possession + biométrie)

Les passkeys, en tant qu’authentificateur unique résistant au phishing, satisfont ou dépassent généralement les exigences de sécurité traditionnelles du MFA en combinant un facteur de possession (l’appareil avec la clé privée) et un facteur de vérification de l’utilisateur (biométrique ou PIN) en une seule étape.

WebAuthn représente l’implémentation sans mot de passe moderne la plus sûre, utilisant la cryptographie asymétrique pour aider à éliminer le vol d’identifiants.

• Inscription : l’application (agissant en tant que partie utilisatrice de WebAuthn) demande à l’authentificateur de l’utilisateur de créer un identifiant. L’authentificateur génère une paire de clés asymétriques spécifiques au domaine de votre application. Le serveur stocke la clé publique, l’ID des identifiants et les métadonnées (par exemple l’attestation de l’authentificateur, lorsque la conformité l’exige). La clé privée ne quitte jamais le dispositif d’authentification ; les utilisateurs ne peuvent pas exporter manuellement les clés privées des authentificateurs de plateforme. L’isolation liée à l’appareil fournit la garantie de sécurité fondamentale de WebAuthn.
• Authentification : le serveur génère une demande d’authentification (challenge) cryptographique unique (généralement une valeur aléatoire). L’authentificateur signe ce challenge à l’aide de la clé privée stockée en toute sécurité sur l’appareil. Le serveur valide la signature à l’aide de la clé publique stockée pour cet identifiant. L’authentificateur lie cryptographiquement la signature au domaine de votre application, ce qui rend la réponse signée invalide sur tout autre site. La liaison au domaine empêche les attaques par phishing, car même si un utilisateur tente de s’authentifier sur un site malveillant, la réponse signée ne fonctionne que pour le domaine légitime.
• Émission de tokens : une fois l’authentification réussie, le fournisseur d’identité émet des tokens (à l’aide de protocoles sécurisés tels qu’OpenID Connect et OAuth 2.0 avec PKCE), qui comprennent généralement un token d’identification pour les revendications d’identité et un token d’accès pour l’autorisation de l’API.
• Établissement de la session : l’application établit une session en utilisant des cookies HttpOnly sécurisés avec les attributs Secure et SameSite, ou un stockage de session côté serveur. Ne stockez jamais de tokens dans localStorage ou sessionStorage en raison des vulnérabilités XSS (Cross-Site Scripting). Générez un nouvel identifiant de session immédiatement après une authentification réussie afin d’éviter les attaques par fixation de session.

• Résistance au phishing : préférez WebAuthn ou les passkeys aux OTP ou aux magic links. La cryptographie asymétrique offre une résistance inhérente au phishing grâce à des demandes d’authentification liées au domaine.
• Stockage des tokens : utilisez des cookies HttpOnly avec les attributs Secure et SameSite, ou un stockage de session en backend. Évitez localStorage et sessionStorage.
• PKCE : utilisez le flux de code d’autorisation avec PKCE pour tous les types de clients afin d’empêcher l’interception des codes d’autorisation.
• Limitation du débit : appliquez une limitation de débit aux endpoints OTP. Les codes à six chiffres ne permettent qu’un million de combinaisons. Mettez en place des limites par adresse IP, par utilisateur, par endpoint et par fenêtre temporelle.
• Sécurité des sessions : régénérez les identifiants de session après une authentification réussie pour empêcher les attaques par fixation de session. Définissez un délai d’inactivité (30 minutes) et une expiration absolue (8-24 heures).
• Récupération des appareils perdus : fournissez des méthodes de réinscription sécurisées. Pour les passkeys, les utilisateurs s’authentifient à partir d’appareils synchronisés. Pour les identifiants non synchronisés, utilisez la récupération par e‑mail vérifié, la récupération administrative ou l’approbation d’un appareil de confiance.
• Attestation : n’utilisez l’attestation de l’authentificateur que lorsque la conformité réglementaire exige une vérification du matériel (par exemple certification FIPS). L’attestation ajoute de la complexité et peut réduire l’adoption.

Méthode	Usage recommandé	Inconvénient en termes de sécurité
Passkeys	Applications grand public, navigateurs modernes, authentification fréquente	Le mécanisme de synchronisation dépend de la sécurité du compte cloud.
WebAuthn (non synchronisé)	Applications d’entreprise, appareils gérés, exigences de sécurité élevées	Les utilisateurs ne peuvent pas s’authentifier facilement à partir de nouveaux appareils.
OTP par e‑mail	Inscription et récupération de compte avec le moins de points de friction	La sécurité est tributaire du compte e‑mail.
TOTP	Sécurité modérée, friction acceptable lors de la configuration	Vulnérable au phishing en temps réel
OTP par SMS	Uniquement en solution de remplacement	Attaques par portage SIM, interception de messages

• TOTP traité comme un facteur résistant au phishing : des acteurs malveillants peuvent soutirer des codes TOTP en temps réel par phishing dans le cadre d’attaques par proxy.
• Limitation inadéquate du débit : des cybercriminels peuvent lancer des attaques par force brute sur des codes à six chiffres sans limitation du débit appropriée dans plusieurs dimensions.
• Stockage incorrect des identifiants : ne stockez que les clés publiques. Ne sauvegardez jamais les clés privées et ne les synchronisez jamais manuellement.
• Flux de récupération peu robustes : implémentez une réinscription sécurisée avant que cela ne soit nécessaire. Testez avec le personnel de support.
• Sécurité de session insuffisante : régénérez les identifiants de session après l’authentification. Un attaquant qui a fixé un identifiant de session peut le détourner sans régénération.

L’authentification sans mot de passe est-elle plus sûre que les mots de passe ?

Oui, si elle est implémentée correctement. Les méthodes sans mot de passe réduisent l’exposition au phishing, au credential stuffing et aux brèches de bases de données. Cependant, la sécurité dépend de l’implémentation. Les OTP par e‑mail ne sont pas intrinsèquement plus sûrs que des mots de passe forts, à condition que des politiques appropriées soient en place.

Les passkeys sont-elles un type d’authentification sans mot de passe ?

Oui. Les passkeys sont des identifiants WebAuthn qui se synchronisent entre les appareils à l’aide de mécanismes sécurisés fournis par la plateforme, combinant la sécurité de WebAuthn avec une meilleure facilité d’utilisation.

L’authentification sans mot de passe peut-elle satisfaire aux exigences du MFA ?

Oui, lorsqu’il s’agit de deux facteurs indépendants. Les passkeys satisfont au MFA en combinant la possession de l’appareil avec la vérification biométrique ou le code PIN de l’appareil. Le TOTP peut être utilisé comme deuxième facteur dans le MFA, mais ne constitue pas un MFA en soi.

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

Vous devez fournir des méthodes de réinscription sécurisées. Pour les passkeys, les utilisateurs s’authentifient depuis un autre appareil synchronisé. Pour les identifiants non synchronisés, utilisez la récupération par e‑mail vérifié avec vérification stricte, la récupération administrative ou l’approbation de l’appareil de confiance.

Les API authentifient-elles directement les utilisateurs ?

Non. Dans les architectures d’identité modernes, le fournisseur d’identité gère l’authentification et émet des tokens. Les API valident les tokens d’accès et appliquent l’autorisation. Elles ne participent pas à la procédure d’authentification.

L’authentification sans mot de passe peut-elle fonctionner dans les environnements d’entreprise ?

Oui. De nombreuses entreprises combinent avec succès WebAuthn avec l’authentification unique (SSO) et les contrôles de gestion des appareils. Les cas d’usage en entreprise préfèrent souvent des identifiants WebAuthn non synchronisés liés à des appareils gérés avec des signaux basés sur le risque.

L’authentification sans mot de passe est essentielle pour combler les lacunes de sécurité les plus courantes dans votre application. L’implémentation de méthodes résistantes au phishing, comme WebAuthn et les passkeys, nécessite une plateforme d’identité robuste.

L’utilisation d’un service comme Auth0 peut simplifier l’authentification sans mot de passe, permettant ainsi aux développeurs de se concentrer sur les fonctionnalités principales de leur application. Explorez notre série d’articles « Introduction à l’IAM » pour en savoir plus sur la gestion des identités et des accès.

En savoir plus

Le contenu de ce document revêt un caractère purement informatif. Il vous revient de vous adresser à des conseillers professionnels pour obtenir des conseils en matière de sécurité, confidentialité, conformité ou conduite des affaires, et de ne pas vous en remettre aux recommandations formulées dans le présent document.