Comment fonctionne la connexion sans mot de passe en coulisses
Vous cliquez sur « Se connecter », votre téléphone demande une empreinte digitale, et vous êtes authentifié. Aucun mot de passe saisi, aucun code copié depuis un email. Si vous avez déjà implémenté des flux d’authentification, cela ressemble probablement à de la magie—ou pire, à une boîte noire que vous devez intégrer sans la comprendre.
Cet article explique comment les passkeys et WebAuthn fonctionnent réellement sous les API du navigateur. Vous comprendrez le flux d’authentification, les primitives cryptographiques impliquées, et les propriétés de sécurité qui rendent l’authentification sans mot de passe basée sur FIDO2 fondamentalement différente des approches plus anciennes comme les liens magiques ou les OTP.
Points clés à retenir
- Les passkeys utilisent la cryptographie à clé publique où la clé privée ne quitte jamais votre appareil, éliminant les secrets partagés que les attaquants peuvent intercepter ou voler.
- L’authentification WebAuthn implique quatre parties : votre frontend, l’API du navigateur, l’authentificateur (trousseau d’appareil ou clé matérielle), et votre serveur.
- La liaison à l’origine fournit une résistance cryptographique au phishing—les identifiants sont liés à des domaines spécifiques et ne fonctionneront pas sur des sites similaires.
- L’interface conditionnelle permet aux invites de passkey d’apparaître dans les suggestions de saisie automatique, créant des expériences d’authentification fluides.
Pourquoi les passkeys ont remplacé les anciennes méthodes « sans mot de passe »
Les liens magiques et les mots de passe à usage unique ont supprimé le champ de mot de passe des formulaires de connexion, mais ils n’ont pas éliminé les secrets partagés. Un lien magique reste un jeton au porteur transmis par email—interceptable, rejouable, et vulnérable au phishing si les utilisateurs cliquent sur des liens provenant de domaines usurpés. Les OTP envoyés par SMS sont vulnérables aux attaques par échange de carte SIM.
Les passkeys résolvent ce problème différemment. Ils utilisent la cryptographie à clé publique où le secret (votre clé privée) ne quitte jamais votre appareil et ne transite jamais sur le réseau. Le serveur ne stocke que votre clé publique, qui est inutile aux attaquants même si la base de données est compromise.
C’est l’idée centrale derrière FIDO2 et WebAuthn : l’authentification se fait par preuve cryptographique de possession, et non par transmission de secrets.
Le flux d’authentification WebAuthn
Lorsqu’un utilisateur s’authentifie avec une passkey, quatre composants interagissent généralement : votre code frontend, l’API WebAuthn du navigateur, l’authentificateur (souvent le trousseau de l’OS, un téléphone, ou une clé de sécurité matérielle), et votre serveur.
Inscription : création de l’identifiant
Lors de l’inscription, votre serveur génère un challenge—une séquence d’octets aléatoires—et l’envoie au navigateur avec votre identifiant de partie de confiance (relying party ID, généralement votre domaine). Votre frontend appelle navigator.credentials.create() avec ces paramètres.
Le navigateur transmet cette requête à l’authentificateur via CTAP (Client to Authenticator Protocol). L’authentificateur génère une nouvelle paire de clés, stocke la clé privée de manière sécurisée, et renvoie la clé publique accompagnée d’une attestation signée.
Votre serveur reçoit et stocke la clé publique, l’identifiant d’identifiant (credential ID), et des métadonnées comme un compteur de signatures. Pas de hachage de mot de passe, pas de secret partagé—juste une clé publique limitée à votre domaine.
Authentification : preuve de possession
Lorsque l’utilisateur revient, votre serveur génère un nouveau challenge. Votre frontend appelle navigator.credentials.get(), et le navigateur sollicite l’authentificateur.
L’authentificateur trouve l’identifiant correspondant à votre RP ID, exige une vérification de l’utilisateur (biométrique, PIN, ou présence), puis signe le challenge avec la clé privée. Cette signature, accompagnée des données de l’authentificateur, retourne à votre serveur.
Votre serveur vérifie la signature par rapport à la clé publique stockée. Si elle correspond, l’utilisateur a prouvé qu’il possède la clé privée sans jamais la transmettre.
Liaison à l’origine : le mécanisme de résistance au phishing
Voici ce qui rend les passkeys véritablement résistantes au phishing plutôt que simplement « plus difficiles à phisher ». L’authentificateur lie cryptographiquement les identifiants à l’origine de la partie de confiance.
Lors de la signature du challenge, l’authentificateur inclut le hachage de l’identifiant de partie de confiance (dérivé de votre domaine) dans les données signées. Si un attaquant crée un site similaire sur g00gle.com, l’identifiant pour google.com ne fonctionnera tout simplement pas—les origines ne correspondent pas, et l’authentificateur ne produira pas de signature valide.
Ce n’est pas un avertissement d’interface utilisateur que les utilisateurs peuvent ignorer. C’est appliqué cryptographiquement au niveau du protocole.
Discover how at OpenReplay.com.
Passkeys synchronisées vs. liées à l’appareil
Les passkeys modernes se synchronisent généralement entre appareils via les trousseaux d’OS—iCloud Keychain d’Apple, Google Password Manager, ou des gestionnaires tiers comme 1Password. Cela améliore considérablement l’utilisabilité puisque les utilisateurs ne perdent pas l’accès en changeant de téléphone.
Les passkeys liées à l’appareil (comme les clés de sécurité matérielles) offrent des garanties plus fortes—la clé privée existe de manière prouvable sur un seul appareil. Pour la plupart des applications web, les passkeys synchronisées offrent une sécurité suffisante avec une meilleure UX. Votre modèle de menace détermine ce qui compte le plus.
Modèles UX modernes : interface conditionnelle
Vous avez probablement vu des invites de passkey apparaître dans les suggestions de saisie automatique du champ nom d’utilisateur. C’est l’interface conditionnelle—le navigateur propose de manière proactive les passkeys disponibles avant que l’utilisateur ne demande explicitement une connexion sans mot de passe.
Implémentez cela en appelant navigator.credentials.get() avec mediation: 'conditional' et en ajoutant autocomplete="username" à votre champ de saisie.
Le navigateur gère la découverte et la présentation.
De nombreuses applications utilisent maintenant l’interface conditionnelle pour migrer les utilisateurs existants : après une connexion réussie par mot de passe, invitez les utilisateurs à enregistrer une passkey pour les sessions futures.
Propriétés de sécurité et frontières de confiance
Les passkeys réduisent considérablement la surface d’attaque, mais elles ne sont pas magiques. La sécurité de la clé privée dépend de l’implémentation de l’authentificateur—généralement l’enclave sécurisée de l’appareil ou le TPM. Si l’appareil lui-même est compromis au niveau matériel, tout est remis en question.
La récupération de compte reste un défi de conception. Lorsque les utilisateurs perdent tous leurs appareils, vous avez besoin de mécanismes de secours qui ne réintroduisent pas les vulnérabilités éliminées par les passkeys.
WebAuthn continue d’évoluer—le niveau 3 est la génération actuelle de la spécification—avec des travaux en cours sur l’authentification inter-appareils et l’attestation d’entreprise. Les fondamentaux couverts ici restent stables.
Conclusion
Les passkeys font passer l’authentification de « vérifier que l’utilisateur connaît un secret » à « vérifier que l’utilisateur possède une clé ». Cela change votre modèle mental : vous ne vérifiez pas des mots de passe contre des hachages, vous vérifiez des signatures cryptographiques contre des clés publiques.
Pour les ingénieurs frontend, l’implication pratique est simple : apprenez les cérémonies d’inscription et d’authentification de l’API WebAuthn, implémentez l’interface conditionnelle pour une découverte fluide, et concevez des chemins de migration qui font passer les utilisateurs des mots de passe aux passkeys de manière progressive.
FAQ
La récupération de compte devient critique lorsque les utilisateurs perdent tous leurs appareils. Les approches courantes incluent des codes de récupération de sauvegarde générés lors de l'inscription, des méthodes d'authentification secondaires comme un email vérifié, ou des processus de vérification d'identité. Le défi consiste à concevoir des solutions de secours qui ne réintroduisent pas les vulnérabilités éliminées par les passkeys, comme les liens magiques vulnérables au phishing ou les codes SMS interceptables.
Oui, les passkeys sont conçues pour la compatibilité multi-plateforme. Les passkeys synchronisées stockées dans les trousseaux de plateforme comme iCloud Keychain ou Google Password Manager fonctionnent sur tous les appareils au sein de cet écosystème. Pour l'authentification inter-écosystème, les utilisateurs peuvent scanner des codes QR pour s'authentifier en utilisant une passkey stockée sur un appareil différent, en exploitant le protocole de transport hybride FIDO2.
Chaque identifiant de passkey est unique et lié à un compte utilisateur spécifique et une partie de confiance. Lorsque plusieurs passkeys existent pour le même domaine, le navigateur ou l'authentificateur présente une interface de sélection permettant aux utilisateurs de choisir quel identifiant utiliser. L'identifiant d'identifiant stocké côté serveur associe chaque passkey à son compte utilisateur correspondant.
Les passkeys résistent aux attaques de l'homme du milieu grâce à la liaison à l'origine. L'authentificateur inclut l'origine exacte dans la réponse d'authentification signée. Si un attaquant intercepte et relaie la tentative d'authentification via un proxy, la non-correspondance d'origine entraîne l'échec de la vérification de signature. La liaison cryptographique rend les attaques de phishing en temps réel inefficaces.
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
