Capacités du client WebAuthn

Passkeys Cheat Sheet — dev-focused WebAuthn reference. Trusted by Ally, Stanford CS & more.

Get Cheat Sheet

WebAuthn est le standard moderne qui propulse les passkeys. Au lieu de s'appuyer sur des mots de passe traditionnels, il utilise la cryptographie à clé publique. Cela permet de s'authentifier avec des passkeys, qui peuvent inclure la biométrie (comme les empreintes digitales ou la reconnaissance faciale) ou des clés de sécurité physiques. Cette évolution renforce la sécurité tout en offrant une bien meilleure expérience utilisateur, puisqu'il n'y a plus de mots de passe à mémoriser.

Le standard WebAuthn Level 3 introduit de nouvelles capacités client (récupérables via l'API de navigateur getClientCapabilities()). L'objectif est d'offrir plus de contrôle et de flexibilité lors de l'intégration des passkeys. Ces nouveautés simplifient grandement l'utilisation des passkeys à travers différents appareils, navigateurs et plateformes, garantissant un parcours utilisateur fluide et cohérent.

Dans cet article, nous allons répondre aux questions suivantes :

1. Que sont les capacités du client WebAuthn ?
2. Quelles sont les capacités client WebAuthn existantes ?
3. Comment ces capacités améliorent-elles l'intégration des passkeys ?
4. Pourquoi ces capacités sont-elles importantes pour les développeurs et les chefs de produit ?

À la fin de votre lecture, vous comprendrez comment ces fonctionnalités peuvent vous aider à créer des parcours d'authentification sécurisés et sans friction, parfaitement alignés avec les attentes actuelles des utilisateurs.

Les capacités du client WebAuthn (Client Capabilities) sont un ensemble de fonctionnalités permettant aux navigateurs et aux plateformes de communiquer le type de fonctions WebAuthn qu'ils supportent. Pour faire simple, c'est comme une liste de contrôle des fonctionnalités qui indique aux sites web quelles méthodes et options d'authentification sont disponibles sur l'appareil d'un utilisateur. Cela nous permet d'adapter les parcours de connexion aux capacités réelles du client, assurant ainsi une expérience plus fluide et sécurisée.

Par exemple, si un navigateur signale qu'il supporte l'authentification biométrique (comme Touch ID), nous pouvons concevoir notre flux de connexion pour proposer l'empreinte digitale. À l'inverse, si certaines fonctionnalités ne sont pas supportées, nous pouvons proposer des alternatives comme un mot de passe ou un code OTP par SMS. Dans la pratique, si une capacité n'est pas supportée ou si l'action est interrompue, cela peut se traduire par une erreur générique du navigateur. Il est donc recommandé d'associer ces résultats à une classification claire des erreurs WebAuthn.

Le standard WebAuthn Level 3 apporte de nouvelles capacités qui rendent l'intégration des passkeys beaucoup plus flexible. La première prise en charge de l'API getClientCapabilities() a vu le jour avec Safari 17.4.

Pour détecter ce support dans le navigateur, voici un petit bout de code bien utile :

// Vérifier si PublicKeyCredential est supporté dans le navigateur actuel
if (typeof PublicKeyCredential === "undefined") {
    console.log("PublicKeyCredential is not supported in this browser.");
}
 
// Vérifier si la méthode getClientCapabilities existe sur PublicKeyCredential
if (typeof PublicKeyCredential.getClientCapabilities === "function") {
    try {
        let capabilities = await PublicKeyCredential.getClientCapabilities();
        console.log(capabilities);
    } catch (error) {
        console.error("Error getting client capabilities:", error);
    }
} else {
    console.log("getClientCapabilities is not supported in this browser");
}

getClientCapabilities() permet aux sites web et aux applications d'interroger le client (navigateur ou appareil) pour savoir quelles fonctions WebAuthn sont prises en charge. En connaissant ces capacités, nous pouvons optimiser l'authentification pour tirer parti des meilleures options disponibles, comme l'authentification biométrique, tout en prévoyant des solutions de repli si besoin.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Regardons de plus près ces capacités et leur impact sur l'intégration des passkeys :

conditionalCreate permet la création automatique de passkeys sous certaines conditions. Une application peut l'utiliser pour générer automatiquement un passkey lors du remplissage automatique d'un mot de passe, à condition que le gestionnaire de mots de passe le supporte. Cette fonction est redoutable pour accélérer l'adoption des passkeys en assurant une transition transparente depuis les mots de passe.

Tout comme conditionalCreate, conditionalGet déclenche automatiquement la connexion par passkey. C'est parfait pour offrir la meilleure UX possible : la connexion devient non seulement sans mot de passe, mais aussi sans nom d'utilisateur (l'utilisateur clique juste sur le passkey suggéré dans une fenêtre ou un menu déroulant). En l'utilisant, on s'assure que la demande d'authentification n'apparaît qu'au bon moment, évitant de solliciter l'utilisateur inutilement.

hybridTransport garantit l'utilisation des passkeys sur différents appareils, facilitant l'authentification croisée (via QR codes et Bluetooth). Par exemple, on peut utiliser un passkey stocké sur son téléphone pour se connecter à un service sur son ordinateur. Cela permet de s'authentifier de manière sécurisée sans avoir à transférer manuellement ses passkeys ou à utiliser des méthodes classiques sur chaque nouvel appareil.

Les authenticators de plateforme, comme Windows Hello, Face ID ou Touch ID, sont intégrés directement aux appareils. Ils offrent une expérience passkey plus rapide et sécurisée en permettant de s'authentifier via la biométrie ou une méthode native (comme le code PIN de l'appareil).

userVerifyingPlatformAuthenticator s'assure que l'authentification par passkey implique une vérification de l'utilisateur (comme un scan d'empreinte ou la reconnaissance faciale), ajoutant ainsi une couche de sécurité indispensable.

La capacité relatedOrigins autorise une authentification fluide entre différents domaines appartenant à une même entreprise (par exemple amazon.com et amazon.de). Si une entreprise gère plusieurs domaines ou sous-domaines, l'utilisateur peut se connecter une seule fois et accéder à tous les services sans devoir se réauthentifier à chaque fois. Cela simplifie la vie de l'utilisateur et s'avère extrêmement précieux pour les environnements internationaux ou multi-services.

La méthode signalAllAcceptedCredentials(options) fournit la liste complète des identifiants (Credential IDs) WebAuthn d'un utilisateur. Les Relying Parties devraient utiliser cette méthode plutôt que signalUnknownCredential() lorsque l'utilisateur est connecté, car cela évite tout risque de fuite de données privées. Elle donne une vue d'ensemble des clés publiques de l'utilisateur, y compris les changements récents qui n'auraient pas encore été mis à jour sur les authenticators connectés.

Prenons un exemple. Un utilisateur (userId: A) possède 2 passkeys dont les Credential IDs encodés en Base64URL sont X et Y. L'utilisateur supprime ensuite le passkey X dans les paramètres de son compte sur le service web (example.com) (la clé publique est donc supprimée). Exécutons maintenant ce code :

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "A", // WebAuthn User Handle, Base64URL.
    allAcceptedCredentialIds: ["Y"],
});

Si l'authenticator est disponible au moment de l'exécution, il supprimera ou masquera le passkey X pour les futures connexions. Toutefois, l'authenticator n'est pas toujours connecté à ce moment-là. Il est donc recommandé d'exécuter ce code régulièrement, par exemple à chaque connexion.

Les passkeys absents de allAcceptedCredentialIds seront retirés ou masqués, parfois de manière irréversible. Il est donc crucial de ne jamais retirer par erreur des Credential IDs valides de la liste. Si un Credential ID valide a été retiré accidentellement, la Relying Party doit immédiatement l'inclure dans un nouvel appel à signalAllAcceptedCredentials(options) pour le "démasquer". Si le passkey n'est pas masqué mais supprimé, il sera très difficile de corriger le tir.

Experiment with passkey flows in the Passkeys Debugger.

Try for Free

La méthode signalCurrentUserDetails(options) signale le nom actuel de l'utilisateur et son nom d'affichage WebAuthn (Display Name). Lorsqu'elle est appelée, le client suit une série d'étapes définies pour exécuter l'action.

Un petit exemple : Un utilisateur avec un User ID WebAuthn A met à jour son nom dans les paramètres de son compte sur un site (example.com). La Relying Party peut alors lancer le code suivant :

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "A", // user ID, Base64URL.
    name: "New user name",
    displayName: "New display name",
});

L'authenticator mettra alors à jour les métadonnées du passkey sauvegardé localement. Le grand avantage est que pour les futures requêtes de Conditional UI / remplissage automatique de passkeys, le menu de sélection affichera le nouveau nom.

La méthode signalUnknownCredential(options) indique qu'un Credential ID WebAuthn n'est pas reconnu par la Relying Party, par exemple si le passkey a été supprimé par l'utilisateur. Contrairement à signalAllAcceptedCredentials(options), elle ne nécessite pas de fournir la liste complète des identifiants acceptés ni le User Handle, évitant ainsi les fuites d'informations envers des appelants non authentifiés.

Voyons cela avec un exemple. Un utilisateur supprime un passkey avec le Credential ID X sur un site (example.com). La clé publique est supprimée côté serveur, mais la clé privée reste sur l'appareil. Cela signifie que lors des futures demandes de Conditional UI avec une liste allowCredentials vide, ce passkey sera toujours proposé. La tentative de connexion échouera puisque la clé publique n'existe plus. La Relying Party devrait alors exécuter :

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "X", // credential ID que l'utilisateur vient d'essayer, Base64URL
});

L'authenticator supprimera ou masquera alors le passkey X pour éviter qu'il ne soit proposé à nouveau.

Le standard WebAuthn Level 3 étant encore à l'état de brouillon (draft), l'adoption de ces capacités n'est pas encore totale. Les navigateurs intègrent ces fonctions progressivement, et le support varie. Voici un aperçu de la disponibilité sur les principaux navigateurs :

Le rythme d'adoption va s'accélérer à mesure que Level 3 gagne en maturité. Si vous souhaitez savoir combien d'utilisateurs peuvent profiter de getClientCapabilities() dès maintenant, vous pouvez consulter des données concrètes sur l'outil gratuit State of Passkeys. Gardez un œil sur les notes de mise à jour des navigateurs pour anticiper une compatibilité plus large.

See how many people actually use passkeys.

View Adoption Data

En tant que développeur, vous vous demandez sûrement ce que cela implique pour vous et comment utiliser ces capacités dans votre application. Voici quelques conseils pratiques.

Gardez à l'esprit que tous les navigateurs ne supportent pas encore l'API getClientCapabilities() (en date de novembre 2024). En attendant, vous pouvez utiliser un polyfill disponible ici.

Utilisez getClientCapabilities() dès que possible dans votre code pour détecter les fonctionnalités supportées au début du chargement de la page ou du flux d'authentification. Cela vous permettra d'adapter l'expérience dynamiquement et d'offrir les fonctionnalités passkey compatibles avec l'appareil. Par exemple, vous pourrez privilégier l'authentification native si elle est supportée, ou proposer des alternatives (comme l'OTP SMS ou les clés de sécurité matérielles) dans le cas contraire.

Si vous ajoutez des passkeys à une application qui utilise encore des mots de passe, conditionalCreate est un accélérateur incroyable pour l'adoption des passkeys. En arrière-plan, lors de la saisie automatique du mot de passe via un gestionnaire compatible (seulement Apple Passwords pour l'instant), un passkey est généré automatiquement et sera privilégié lors des prochaines connexions.

Pour garantir non seulement une bonne adoption des passkeys, mais aussi une utilisation fréquente pour la connexion, vérifiez si l'appareil supporte la Conditional UI (via conditionalGet). Cela permet d'inciter les utilisateurs à se servir du passkey fraîchement créé, car il est suggéré de manière proactive par le système d'exploitation et demande encore moins d'effort que de remplir un mot de passe.

Servez-vous de hybridTransport pour activer l'authentification croisée (via QR code et Bluetooth). Vos utilisateurs pourront ainsi se connecter facilement depuis leur smartphone, même s'ils naviguent sur votre service depuis leur ordinateur de bureau.

Les capacités du client WebAuthn (Client Capabilities) représentent une avancée majeure pour combler les lacunes actuelles des passkeys. Dans cet article, nous avons abordé les points clés :

1. Que sont les capacités du client WebAuthn ? Nous avons vu comment ces fonctionnalités permettent aux navigateurs de signaler ce qu'ils supportent, donnant aux développeurs plus de contrôle sur les flux d'authentification.
2. Quelles sont ces capacités ? Nous avons listé les nouveautés du standard Level 3, incluant getClientCapabilities, conditionalCreate, hybridTransport, etc.
3. Comment améliorent-elles l'intégration des passkeys ? En fluidifiant l'intégration, en optimisant l'usage multi-appareils et en renforçant la sécurité.
4. Pourquoi sont-elles importantes pour les développeurs ? Elles aident à créer des expériences de connexion fluides et modernes, rendant l'implémentation plus simple et redoutablement efficace.

Nous vous encourageons vivement à explorer les nouveautés de WebAuthn Level 3 et à suivre leur adoption par les navigateurs. Si vous souhaitez implémenter des passkeys et tirer parti de ces capacités avancées, n'hésitez pas à nous contacter pour un accompagnement sur mesure.

Appelez getClientCapabilities() tôt lors du chargement de la page ou du flux d'authentification pour détecter dynamiquement les fonctionnalités prises en charge. Cela vous permet de proposer l'authentification native lorsqu'elle est disponible, ou de basculer vers des alternatives comme les OTP SMS ou les clés de sécurité matérielles dans le cas contraire.

signalAllAcceptedCredentials nécessite la liste complète des Credential IDs valides et le User Handle WebAuthn ; elle ne doit donc être appelée que lorsque l'utilisateur est connecté pour éviter les fuites de confidentialité. signalUnknownCredential signale un seul Credential ID non reconnu sans exiger la liste complète, ce qui permet de l'appeler en toute sécurité même si l'utilisateur n'est pas authentifié (par exemple après un échec de connexion).

La capacité relatedOrigins permet une authentification transparente entre différents domaines détenus par la même organisation, par exemple amazon.com et amazon.de. Les utilisateurs peuvent se connecter une seule fois et accéder à toutes les plateformes sans se réauthentifier sur chaque domaine, ce qui réduit considérablement la friction dans les environnements internationaux ou multi-services.

En date de novembre 2024, tous les navigateurs ne prennent pas encore en charge getClientCapabilities(). Vous pouvez utiliser le polyfill disponible sur github.com/MasterKale/webauthn-polyfills comme solution temporaire. L'adoption devrait s'accélérer à mesure que le standard WebAuthn Level 3 gagne en maturité. Safari 17.4, Chrome 133, Edge 133 et Firefox 135 l'intègrent déjà.

À propos de Corbado

Corbado est la Passkey Intelligence Platform pour les équipes CIAM qui gèrent l'authentification client à grande échelle. Nous vous montrons ce que les logs IDP et les outils d'analytics génériques ne voient pas : quels appareils, versions d'OS, navigateurs et gestionnaires de credentials prennent en charge les passkeys, pourquoi les enrôlements ne deviennent pas des connexions, où le flux WebAuthn échoue et quand une mise à jour OS ou navigateur casse silencieusement la connexion — le tout sans remplacer Okta, Auth0, Ping, Cognito ni votre IDP interne. Deux produits : Corbado Observe ajoute l'observabilité pour les passkeys et toute autre méthode de connexion. Corbado Connect apporte des passkeys managés avec analytics intégrés (aux côtés de votre IDP). VicRoads gère les passkeys pour plus de 5M d'utilisateurs avec Corbado (+80 % d'activation passkey). Parler à un expert Passkey →