Passkeys, FIDO2 et SSO: comment déployer l’authentification sans mot de passe dans les services web

Les passkeys s’imposent comme la pièce la plus visible d’un mouvement plus large: réduire la dépendance aux mots de passe, principale porte d’entrée des attaques par hameçonnage et des réutilisations d’identifiants. Portée par l’alliance FIDO et standardisée par le W3C via WebAuthn, cette approche s’appuie sur la cryptographie à clé publique et sur des mécanismes d’authentification forte déjà présents dans les smartphones et les navigateurs modernes.

Le basculement ne se résume pas à supprimer le mot de passe. Dans une organisation, il faut composer avec des parcours de connexion existants, des annuaires, des politiques de sécurité, des contraintes réglementaires et une réalité opérationnelle: les utilisateurs perdent des appareils, changent de téléphone, et se connectent depuis des environnements hétérogènes. Le sujet devient une question d’architecture: comment articuler FIDO2, SSO et les standards d’identité, sans créer de nouveaux angles morts.

Les acteurs du numérique convergent sur une même promesse: rendre l’authentification plus simple et plus robuste. Apple, Google et Microsoft ont intégré les passkeys à leurs écosystèmes, ce qui abaisse la barrière d’adoption côté utilisateur. Pour les équipes produit et sécurité, le chantier consiste à intégrer les bons protocoles, choisir les bons modes de déploiement, et définir des mécanismes de secours qui ne ruinent pas le niveau de sécurité recherché.

WebAuthn et CTAP2: la base technique des passkeys dans un navigateur

Le cur de l’authentification sans mot de passe repose sur un couple de standards: WebAuthn côté navigateur et CTAP2 pour dialoguer avec un authentificateur (smartphone, clé matérielle, module intégré). WebAuthn est une API standardisée par le W3C qui permet à un service web de demander une inscription ou une authentification basée sur une paire de clés cryptographiques. CTAP2, issu de l’alliance FIDO, définit comment le navigateur communique avec l’authentificateur, en USB, NFC ou Bluetooth.

Dans un schéma typique, lors de l’inscription, le service crée un défi cryptographique et le navigateur sollicite l’authentificateur. Celui-ci génère une paire de clés: une clé privée stockée de manière protégée sur l’appareil, et une clé publique transmise au serveur. À la connexion, le serveur envoie un nouveau défi, l’authentificateur signe la réponse avec la clé privée, et le serveur vérifie la signature avec la clé publique enregistrée. La valeur opérationnelle est immédiate: la clé privée ne quitte pas l’appareil, et la signature est liée au domaine, ce qui limite fortement les attaques par phishing sur des sites imitateurs.

Les passkeys sont une forme d’ identifiant WebAuthn pensée pour l’usage grand public: une expérience de connexion fluide, souvent déclenchée par la biométrie ou un code de déverrouillage. Sur le plan technique, elles s’appuient sur des credentials WebAuthn, mais avec une ergonomie et une synchronisation possibles entre appareils d’un même écosystème. Ce point est décisif pour l’adoption, mais il impose aux services de gérer des cas concrets: un utilisateur peut disposer de plusieurs passkeys, sur plusieurs appareils, et l’application doit présenter des parcours clairs de gestion et de révocation.

Les choix d’implémentation comptent. L’usage d’un authentificateur plateforme (intégré au téléphone ou à l’ordinateur) n’a pas les mêmes propriétés qu’une clé matérielle externe. Les organisations qui visent un niveau d’assurance élevé privilégient souvent des authentificateurs matériels certifiés, car ils réduisent l’exposition aux compromissions logicielles. Dans tous les cas, l’intégration WebAuthn exige une gestion rigoureuse des paramètres: origine, identifiant de partie de confiance, politique d’attestation, et stockage sécurisé des clés publiques et métadonnées associées.

FIDO2 en entreprise: arbitrer entre clés matérielles et authentificateurs mobiles

Dans un contexte professionnel, FIDO2 devient un instrument de politique de sécurité. L’objectif n’est pas seulement de remplacer un mot de passe, mais de réduire les coûts des incidents liés aux comptes compromis et les charges de support. Les attaques par réutilisation d’identifiants et les campagnes de hameçonnage ciblant les employés restent une source majeure de compromission. Une authentification basée sur des clés cryptographiques, liée au service légitime, coupe une partie de ce risque à la racine.

Le premier arbitrage oppose souvent la clé de sécurité matérielle (USB/NFC) et l’authentificateur mobile. La clé matérielle apporte une portabilité et un contrôle tangibles: elle peut être inventoriée, attribuée, remplacée, et son usage peut être imposé sur des postes partagés. Le mobile, lui, capitalise sur un objet déjà présent, avec une biométrie intégrée et une expérience souvent plus acceptable. Mais il introduit des dépendances: gestion du parc, politiques MDM, renouvellement des terminaux, et risques liés aux sauvegardes ou aux synchronisations d’identifiants.

Le second arbitrage concerne le niveau d’assurance. Une entreprise peut exiger une authentification phishing-resistant pour les accès sensibles, mais accepter des mécanismes plus souples pour des applications à faible risque. Ce découpage doit être explicite et documenté: accès administrateurs, accès VPN, outils financiers, et consoles cloud ne se traitent pas comme un portail intranet. Les référentiels de bonnes pratiques publiés par les organismes de cybersécurité recommandent généralement de hiérarchiser les contrôles selon l’impact métier et la criticité des données.

Un déploiement FIDO2 crédible passe aussi par les scénarios de secours. Perte de clé, téléphone cassé, changement de poste, départ d’un collaborateur: chaque cas doit avoir une procédure, sinon l’organisation réintroduit des contournements comme des réinitialisations faibles ou des codes de secours mal protégés. Les bonnes pratiques consistent à prévoir une seconde méthode forte dès l’enrôlement, à encadrer strictement les réinitialisations via le support, et à journaliser les événements d’identité pour alimenter la détection d’anomalies.

SSO, SAML et OpenID Connect: où placer les passkeys dans la chaîne d’identité

Dans les services web, l’authentification n’est souvent qu’un maillon: le SSO centralise l’accès à plusieurs applications via un fournisseur d’identité. Deux familles de protocoles dominent: SAML 2.0, très présent dans les environnements historiques, et OpenID Connect (sur OAuth 2.0), standard de fait pour les applications modernes et les API. Les passkeys ne remplacent pas ces protocoles: elles remplacent la méthode d’authentification utilisée par le fournisseur d’identité, ou par l’application quand elle gère elle-même la connexion.

Le modèle le plus robuste consiste à intégrer les passkeys au niveau du fournisseur d’identité. L’utilisateur s’authentifie une fois, avec WebAuthn, puis le fournisseur émet des assertions SAML ou des jetons OpenID Connect pour les applications. Cette approche concentre les politiques de sécurité, la gestion du cycle de vie et la journalisation au même endroit. Elle limite aussi la prolifération de logiques d’authentification hétérogènes dans chaque application, ce qui réduit les erreurs d’implémentation.

Il existe un second modèle, fréquent dans les produits grand public: l’application intègre directement WebAuthn et gère les passkeys en propre. Le gain est une expérience maîtrisée et une dépendance moindre à un fournisseur externe. Le coût est une responsabilité accrue: gestion des comptes, récupération, détection de fraude, conformité, et maintenance des bibliothèques de sécurité. Pour des services à forte exposition, la question n’est pas seulement technique: elle touche au niveau de maturité de l’équipe et à sa capacité à opérer une brique d’identité dans la durée.

Dans les deux cas, le placement des passkeys doit être cohérent avec la gestion des sessions. Une authentification forte n’empêche pas le vol de session si les cookies ne sont pas protégés, si les tokens sont trop longs, ou si la détection d’appareils compromis est absente. Les organisations qui migrent vers WebAuthn sans revoir la sécurité applicative globale prennent le risque de déplacer le problème. Les standards d’identité, OIDC et SAML, doivent s’accompagner de politiques de durée de session, de rotation de jetons, et de contrôle des appareils.

Intégration web: parcours d’enrôlement, récupération de compte et métriques de sécurité

Une intégration réussie se joue dans les détails du produit. Le premier point est l’enrôlement: proposer la création d’une passkey au bon moment, avec un texte clair sur ce qui est stocké et sur la manière de se reconnecter. Les parcours efficaces évitent de forcer trop tôt, mais rendent l’option visible après une connexion réussie. Le service doit aussi gérer les comptes multi-appareils: plusieurs passkeys par utilisateur, nommage des appareils, et possibilité de révoquer un authentificateur perdu.

La récupération de compte est le point de rupture classique. Beaucoup de systèmes sans mot de passe réintroduisent une faiblesse via l’email ou le SMS. Or le SMS reste exposé à des détournements, et l’email dépend de la sécurité de la boîte de réception. Une approche plus solide consiste à exiger une seconde passkey, une clé matérielle de secours, ou une procédure de rétablissement encadrée, avec vérifications d’identité adaptées au risque. Dans une entreprise, cela passe souvent par un processus ITSM avec contrôle d’identité et validation hiérarchique pour les comptes sensibles.

La mise en production implique une stratégie de compatibilité. Tous les environnements ne supportent pas WebAuthn de manière homogène, et certains postes verrouillés ou navigateurs anciens peuvent bloquer l’adoption. Les services doivent prévoir un mode de repli, mais ce repli doit rester sous contrôle. Une méthode fréquente consiste à conserver le mot de passe pendant une période de transition, tout en imposant progressivement WebAuthn sur les accès les plus critiques. La trajectoire doit être mesurée, sinon la dette de sécurité se fige.

Les métriques sont le dernier levier, souvent négligé. Taux d’activation des passkeys, part des connexions réalisées via WebAuthn, volume de réinitialisations de compte, temps moyen de résolution au support, et taux d’échecs d’authentification par navigateur: ces indicateurs permettent d’arbitrer entre ergonomie et sécurité. Ils servent aussi à détecter des attaques, par exemple une hausse d’échecs sur un segment géographique ou sur un flux de récupération de compte. Sans observabilité, l’authentification forte devient une promesse difficile à piloter.

Bonnes pratiques: attestation, anti-phishing et limites opérationnelles des passkeys

WebAuthn apporte une résistance structurelle au phishing via la liaison au domaine, mais la sécurité dépend de la configuration. Le choix de l’attestation est un sujet sensible: exiger une attestation matérielle peut renforcer le contrôle du type d’authentificateur autorisé, utile en entreprise, mais cela peut aussi compliquer l’expérience et soulever des questions de vie privée. Beaucoup de services optent pour une politique d’attestation plus souple, et s’appuient sur des listes de métadonnées et des contrôles côté fournisseur d’identité.

Les passkeys ne règlent pas tout. Elles n’empêchent pas un utilisateur de valider une action frauduleuse si l’interface est trompeuse, ni un malware de détourner une session déjà ouverte. La sécurité doit rester multicouche: protection des sessions, détection d’anomalies, gestion des appareils, et durcissement des parcours à risque comme les changements d’email ou de numéro de téléphone. Dans un service exposé, la réduction du phishing sur la connexion peut déplacer la pression des attaquants vers la récupération de compte ou l’ingénierie sociale du support.

La question de la portabilité reste aussi un point d’attention. Les passkeys synchronisées améliorent l’expérience, mais elles reposent sur des mécanismes de sauvegarde et de synchronisation propres aux écosystèmes. Pour une organisation, cela pose la question du contrôle: un départ d’employé, un changement d’appareil ou une politique de séparation des usages personnels et professionnels doivent être anticipés. Les stratégies les plus strictes privilégient des authentificateurs gérés, ou imposent des passkeys liées à des profils d’entreprise.

Le déploiement doit se faire avec une doctrine claire: quels comptes passent en priorité, quels flux doivent devenir phishing-resistant, quels mécanismes de secours sont autorisés, et quelles preuves sont exigées pour une récupération. À défaut, l’authentification sans mot de passe devient un empilement d’exceptions. Dans les projets les plus maîtrisés, la bascule s’accompagne d’une politique de réduction progressive des mots de passe, jusqu’à leur suppression sur les périmètres où l’organisation contrôle les appareils et les identités.