Passkey
Une passkey est un moyen d'authentification résistant au phishing, fondé sur la cryptographie asymétrique, conçu pour remplacer les mots de passe.
- Synonyme
- Clé d'accès FIDO2
Définition
Une passkey est un moyen d'authentification moderne, résistant au phishing, fondé sur la cryptographie asymétrique et conçu pour remplacer les mots de passe dans les parcours d'authentification utilisateur. Elle est généralement créée et stockée dans un authentificateur sécurisé, par exemple un authentificateur de plateforme sur un terminal ou une clé matérielle itinérante, et repose sur la possession d'une clé privée ainsi que, si nécessaire, sur une vérification locale de l'utilisateur. Comme la clé privée ne quitte jamais l'authentificateur et que l'authentification est liée à l'origine, les passkeys réduisent fortement les risques de phishing et de rejeu.
Que se passe-t-il réellement quand on utilise une passkey ?
Une passkey change une propriété fondamentale de l'authentification : l'utilisateur ne prouve plus son identité en envoyant un secret réutilisable au service. L'authentification repose à la place sur la cryptographie à clé publique.
Lors de la création de la passkey, l'authentificateur génère une paire de clés cryptographiques. Le service conserve la clé publique, tandis que la clé privée reste protégée par l'authentificateur.
Lors de l'authentification, le service envoie un challenge unique. L'authentificateur utilise la clé privée pour signer ce challenge, et le service vérifie le résultat avec la clé publique correspondante. La clé privée elle-même n'est jamais envoyée au service.
Cette distinction est importante. Avec un mot de passe, l'utilisateur et le service dépendent in fine de la connaissance d'un secret partagé. Avec une passkey, le service vérifie une preuve cryptographique de possession.
Comment fonctionne une authentification par passkey
Appareil de l'utilisateur / authentificateur
La clé privée reste dans l'authentificateur
Service (relying party)
La clé publique peut être stockée par le service
- 1
Appareil de l'utilisateur / authentificateur
Demande de connexion
L'utilisateur lance une authentification.
- 2
Service (relying party)
Challenge d'authentification
Le service génère un challenge cryptographique unique.
- 3
Appareil de l'utilisateur / authentificateur
Challenge transmis à l'authentificateur
L'authentificateur reçoit le challenge pour le bon service.
- 4
Appareil de l'utilisateur / authentificateur
Signature avec la clé privée
L'authentificateur signe le challenge avec la clé privée associée à ce credential.
- 5
Service (relying party)
Vérification avec la clé publique
Le service vérifie la signature avec la clé publique enregistrée lors de l'enrôlement.
- 6
Service (relying party)
Authentification réussie
Si la preuve cryptographique est valide et que les conditions de vérification de l'utilisateur requises sont remplies, l'authentification réussit.
Version texte du schéma
1. Demande de connexion — L'utilisateur lance une authentification. 2. Challenge d'authentification — Le service génère un challenge cryptographique unique. 3. Challenge transmis à l'authentificateur — L'authentificateur reçoit le challenge pour le bon service. 4. Signature avec la clé privée — L'authentificateur signe le challenge avec la clé privée associée à ce credential. 5. Vérification avec la clé publique — Le service vérifie la signature avec la clé publique enregistrée lors de l'enrôlement. 6. Authentification réussie — Si la preuve cryptographique est valide et que les conditions de vérification de l'utilisateur requises sont remplies, l'authentification réussit. La clé privée reste dans l'authentificateur. La clé publique peut être stockée par le service.
Pourquoi c'est important
Les passkeys sont au cœur du passage vers une authentification résistante au phishing et des stratégies modernes de passwordless.
Les passkeys, une excellente porte d'entrée vers la cryptographie moderne
Les passkeys sont intéressantes bien au-delà de la disparition du mot de passe. Elles offrent un moyen concret de comprendre l'un des fondements de la cybersécurité moderne : la cryptographie asymétrique.
Une clé privée prouve la possession sans être divulguée. Une clé publique permet à un autre système de vérifier la preuve cryptographique obtenue. Ces mêmes concepts fondamentaux — clés publiques et privées, preuves cryptographiques et signatures — se retrouvent partout en cybersécurité.
C'est pourquoi comprendre la cryptographie à clé publique et la PKI reste si utile pour les ingénieurs cybersécurité. Les passkeys réutilisent ces fondements cryptographiques, même si une architecture passkey ne doit pas être confondue avec une infrastructure à clés publiques X.509 traditionnelle, construite autour d'autorités de certification et de chaînes de certificats.
Comprendre le mécanisme compte davantage que mémoriser l'acronyme. Une fois que l'on comprend pourquoi la clé privée doit rester privée, ce que prouve une signature et ce que la clé publique permet de vérifier, FIDO2 et WebAuthn deviennent beaucoup plus simples à appréhender.
Mot de passe vs passkey
| Mot de passe | Passkey | |
|---|---|---|
| Preuve utilisée | Connaissance d'un secret partagé | Preuve cryptographique de possession |
| Ce que stocke le service | Un vérificateur / hash du mot de passe | Une clé publique |
| Ce que l'utilisateur envoie comme preuve | Une information dérivée d'un secret réutilisable | Une signature générée pour un challenge |
| Élément privé | Doit rester connu et protégé par l'utilisateur | La clé privée reste protégée par l'authentificateur |
| Résistance au phishing | Peut être saisi sur un site malveillant | Le credential est lié à la relying party / l'origine légitime |
La passkey aide aussi à comprendre l'évolution de l'authentification
Dans notre formation IAM, nous utilisons une autre grille de lecture utile de l'authentification : distinguer les mécanismes explicites, implicites et calculés. Elle ne remplace pas les catégories classiques connaissance, possession et inhérence. C'est une façon de comprendre l'expérience utilisateur et le processus de décision autour de l'authentification.
Explicite
Un mécanisme explicite exige une action d'authentification consciente de l'utilisateur. Saisir un mot de passe, taper un code reçu par SMS ou approuver une demande d'authentification en sont des exemples typiques.
- Mot de passe
- Code SMS
- Approbation mobile
Implicite
Un mécanisme implicite peut établir une partie de la preuve d'authentification sans demander à l'utilisateur de fournir manuellement un secret réutilisable. Une clé privée associée à un appareil ou à un authentificateur en est un bon exemple : l'opération cryptographique a lieu sans exposer la clé au service.
- Clé privée liée à l'appareil
Calculé
Les signaux calculés proviennent du contexte et du comportement. Un système d'identité peut évaluer des informations comme l'adresse IP, la fréquence de connexion, la localisation, l'heure de connexion ou le comportement de l'utilisateur pour estimer le risque d'une tentative d'authentification.
- Adresse IP
- Fréquence de connexion
- Lieu et heure
- Comportement utilisateur
Alors, une passkey est-elle explicite ou implicite ?
La réponse est plus intéressante que le choix d'une seule case.
La possession et l'utilisation de la clé privée peuvent être largement implicites : l'utilisateur ne saisit pas la clé, ne la copie pas et ne la transmet pas au service. C'est l'authentificateur qui réalise l'opération cryptographique.
Cependant, l'authentificateur peut tout de même exiger une vérification locale de l'utilisateur, par exemple un geste biométrique ou le code PIN de l'appareil. Cette interaction est visible pour l'utilisateur, mais la donnée biométrique ou le PIN ne devient pas un secret envoyé au site web.
Un parcours d'authentification moderne peut donc combiner possession cryptographique, vérification locale de l'utilisateur et signaux de risque calculés. L'authentification consiste de moins en moins à demander un secret, et de plus en plus à établir un niveau de confiance suffisant pour un accès donné.
Standards de référence
Les passkeys reposent sur l'écosystème FIDO2, qui combine WebAuthn pour les applications web et des protocoles d'authentificateur comme CTAP. Pour l'implémentation et les détails normatifs, référez-vous aux spécifications primaires plutôt qu'à la documentation d'un produit.
- FIDO Alliance — Passkeys
- W3C — Web Authentication (WebAuthn) niveau 3— Recommandation W3C, 25 août 2026
- FIDO Alliance — Client to Authenticator Protocol (CTAP)
La passkey sécurise la connexion. Et ensuite ?
Une authentification par passkey réussie fournit une preuve cryptographique forte à un instant donné. Mais une fois l'authentification réussie, la plupart des applications établissent une session afin que l'utilisateur n'ait pas à s'authentifier de nouveau pour chaque action.
À partir de ce moment, l'application ne valide plus la passkey à chaque clic. Elle fait largement confiance à la session issue de l'authentification.
Cette distinction est essentielle. Protéger la cérémonie d'authentification et protéger la session qui en résulte sont deux problèmes liés, mais ce ne sont pas le même problème.
L'authentification est un instant. La confiance a un cycle de vie.
Une authentification forte ne signifie pas une confiance permanente. La passkey renforce la preuve d'authentification. L'Access Management doit ensuite continuer à évaluer la confiance.
- 1
Passkey : preuve forte
Enrôlement
Le credential ou l'authentificateur est associé à l'identité.
- 2
Passkey : preuve forte
Authentification
L'utilisateur prouve la possession de la passkey et réalise la vérification utilisateur requise.
- 3
Access Management : évaluation de la confiance
Session
L'application crée une session de confiance.
- 4
Access Management : évaluation de la confiance
Navigation
L'utilisateur continue d'interagir avec les applications et les ressources.
- 5
Access Management : évaluation de la confiance
Action sensible
Le risque peut être très différent de celui observé lors de la connexion initiale.
- 6
Access Management : évaluation de la confiance
Réauthentification / décision de risque
Le système peut demander une preuve plus forte, évaluer un contexte supplémentaire ou mettre fin à la session.
La connexion n'est pas la fin du contrôle d'accès
L'une des limites des architectures d'authentification traditionnelles est leur vision statique de la confiance. L'utilisateur s'authentifie avec succès, et la session qui en résulte peut ensuite rester considérée comme fiable alors même que le contexte change.
Or le contexte change. L'appareil peut changer d'état. L'adresse IP peut changer. Le comportement peut devenir inhabituel. L'utilisateur peut passer de la consultation d'informations à une transaction sensible. Les privilèges rattachés à l'identité peuvent aussi évoluer.
C'est pourquoi un Access Management moderne ne devrait pas traiter l'authentification comme un événement binaire unique. L'authentification établit un niveau de confiance. L'architecture doit ensuite décider combien de temps cette confiance reste suffisante et à quel moment une vérification supplémentaire devient nécessaire.
Le contexte change après la connexion
1 / 3
Connexion
Exemples de signaux
- • appareil
- • réseau
- • localisation
- • méthode d'authentification
- • contexte d'identité
2 / 3
Navigation
Exemples de signaux
- • comportement
- • ressources consultées
- • navigation inhabituelle
- • changements de contexte
- • caractéristiques de la session
3 / 3
Transaction
Exemples de signaux
- • sensibilité de l'action
- • montant ou impact métier
- • privilège demandé
- • sensibilité de la ressource
- • niveau de risque actuel
Un utilisateur peut donc s'authentifier légitimement et atteindre malgré tout un point où le niveau de confiance initial n'est plus suffisant pour l'action tentée. Une architecture d'authentification moderne peut alors réagir en autorisant l'action, en demandant une vérification supplémentaire, en restreignant la session ou en refusant l'action.
Ce qu'une passkey ne remplace pas
Les passkeys résolvent extrêmement bien un problème d'authentification important. Il ne faut pas attendre d'elles qu'elles remplacent les autres contrôles nécessaires autour d'une identité authentifiée.
Sécurité des sessions
Après l'authentification, les applications s'appuient généralement sur des cookies ou des jetons de session. Protéger le credential ne dispense donc pas de protéger, limiter et surveiller les sessions authentifiées.
Enrôlement des authentificateurs
Ajouter un nouvel authentificateur modifie les capacités d'authentification futures d'un compte. L'enrôlement doit donc être traité comme un événement d'identité sensible, et non comme une simple préférence utilisateur.
Récupération de compte
Un mécanisme d'authentification fort perd une partie de sa valeur si la récupération de compte repose sur un processus nettement plus faible. Les procédures de récupération, de réinitialisation et de support doivent donc être conçues avec un niveau d'assurance cohérent avec le compte protégé.
Comportement après authentification
Une authentification légitime ne garantit pas que chaque action ultérieure le soit. Des changements de permissions, des accès inhabituels à des ressources sensibles ou un comportement incohérent avec le rôle attendu peuvent justifier des contrôles supplémentaires.
Une architecture prête pour les passkeys doit aussi répondre à ces questions…
- Comment les nouveaux authentificateurs sont-ils enrôlés ?
- Comment la récupération de compte est-elle réalisée ?
- Combien de temps une session authentifiée peut-elle rester de confiance ?
- Que se passe-t-il quand le contexte ou l'appareil change ?
- Quelles actions exigent une authentification renforcée (step-up) ?
- Comment les sessions sont-elles révoquées après un événement de sécurité ?
- Comment les événements sensibles d'authentification et de récupération sont-ils journalisés ?
- Que se passe-t-il quand le comportement observé ne correspond plus au contexte attendu de l'utilisateur ?
Passkeys et authentification adaptative sont complémentaires
Une passkey peut fournir un mécanisme d'authentification très fort, tandis qu'un système d'authentification adaptative décide quand cette preuve est suffisante.
L'authentification adaptative évalue des signaux comme le contexte, le comportement et le risque. Selon ces signaux, le système peut maintenir la session en cours, demander une vérification supplémentaire ou restreindre l'accès.
Les deux approches résolvent donc des parties différentes du même problème : la passkey renforce la preuve d'authentification, tandis que les contrôles adaptatifs évaluent en continu si le niveau de confiance obtenu reste approprié.
Entrées liées du glossaire
- Authentification adaptative
- Gestion des accès (Access Management)
- Authentification multifacteur (MFA)
- Zero Trust
Pourquoi les passkeys restent essentielles
Aucune de ces considérations ne réduit la valeur des passkeys. Supprimer les mots de passe réutilisables de l'authentification élimine une catégorie importante d'attaques sur les identifiants et fournit une base bien plus solide aux architectures d'accès modernes.
Il s'agit simplement de rappeler que l'authentification est une étape d'un cycle de confiance plus long. Plus cette première étape devient forte, plus il est utile de concevoir le reste du cycle avec le même niveau d'exigence.
Le point de vue d'Ariovis
Une passkey n'est pas intéressante simplement parce qu'elle supprime un mot de passe. Elle change la manière dont la preuve d'identité est établie.
Pour nous, comprendre ce mécanisme est plus utile que de traiter le passwordless comme une fonctionnalité produit. L'architecture d'authentification doit combiner la preuve cryptographique, la vérification de l'utilisateur et les signaux contextuels appropriés selon le risque du parcours.
L'objectif n'est pas de rendre chaque authentification invisible. Il s'agit d'éviter la friction inutile quand la confiance est déjà suffisante, et d'exiger une preuve plus forte quand le contexte le justifie.
Offres associées
Aller plus loin : l'authentification fait partie de notre formation IAM
Notre formation IAM couvre les mécanismes d'authentification, la cryptographie à clé publique, FIDO2, l'Access Management et la distinction entre signaux d'authentification explicites, implicites et calculés.
Découvrir notre formation IAM →Les pièges courants
- Une erreur courante consiste à négliger les enjeux de récupération de compte, de gestion du cycle de vie en entreprise et de portabilité entre appareils.
Standards et protocoles
- FIDO Alliance
- W3C WebAuthn
- FIDO2/WebAuthn
- CTAP2
Explorer la même catégorie
Approfondir l'authentification moderne
Comprendre la preuve
Renforcer l'authentification
Vous envisagez de déployer des passkeys ?
Comprendre la technologie est la partie la plus simple. La déployer dans un système d'information réel soulève un tout autre ensemble de questions.
Quelles populations faire évoluer en premier ? Quelles applications supportent déjà une authentification moderne ? Que deviennent les applications historiques ? Comment les utilisateurs récupéreront-ils leur compte ? Quelles méthodes d'authentification restent disponibles pendant la transition ? Comment traiter les sessions et les actions sensibles après la connexion ?
C'est à ce moment qu'un projet passkey devient un projet d'architecture d'authentification.
Votre architecture d'authentification est-elle prête pour les passkeys ?
Passez en revue six dimensions avant de définir une trajectoire passwordless.
Aucun email, aucun formulaire : vos réponses restent dans votre navigateur et ne sont envoyées nulle part.
Passez de la passkey à une trajectoire d'authentification
Nous aidons les organisations à évaluer leur architecture d'authentification actuelle, à identifier des cas d'usage passwordless réalistes et à définir une cible progressive couvrant les utilisateurs, les applications, l'enrôlement, la récupération, les sessions et les politiques d'accès.
L'objectif n'est pas de remplacer une technologie pour le principe. Les capacités existantes doivent d'abord être comprises, puis conservées, étendues ou modifiées selon les parcours cibles.
Commencer par le parcours d'authentification, pas par le produit
Un projet passwordless ne devrait pas partir du principe que l'organisation doit remplacer sa plateforme d'identité.
Les premières questions portent sur les utilisateurs, les applications, le risque, l'enrôlement, la récupération, les sessions et les contraintes d'exploitation. Les capacités existantes couvrent peut-être déjà une partie de la cible.
Les choix technologiques viennent après la compréhension des parcours d'authentification et de l'architecture.