API Signal WebAuthn : Mettre à jour et supprimer des passkeys côté client

L'écosystème des passkeys est en pleine évolution. Pour accompagner ce changement, la norme WebAuthn sous-jacente évolue rapidement. Les nouvelles fonctionnalités naissent souvent d'un « explainer » technique sur GitHub avant de devenir une « pull request » intégrée à la norme, une fois qu'elles ont été suffisamment débattues. Récemment, cette pull request a été ajoutée au projet de norme sous le nom d'API Signal WebAuthn. Dans cet article, nous aborderons les points suivants :

• Pourquoi l'API Signal WebAuthn est-elle nécessaire : Quels cas d'usage l'API Signal WebAuthn prend-elle en charge ?
• Comment fonctionne l'API Signal WebAuthn : Comment l'API Signal WebAuthn fonctionne-t-elle exactement ? Quelles sont les recommandations pour les parties de confiance ?

Au moment de la mise à jour de cet article en janvier 2025, l'API Signal WebAuthn est activée par défaut depuis Chrome 132. Elle était auparavant connue sous le nom d'API Reporting avant d'être renommée pour éviter les conflits avec une autre API du même nom.

L'API Signal WebAuthn répond à des cas d'usage spécifiques liés à la gestion des passkeys côté client. Plus précisément, elle aide à synchroniser les informations entre la partie de confiance (RP) et les authentificateurs qui font partie des systèmes d'exploitation côté client. Voici les principaux cas d'usage :

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Lorsqu'un passkey est créé, il contient plusieurs informations : user.id, user.name et user.displayName. Le passkey lui-même est identifié par un ID de l'identifiant (Credential ID) unique.

• user.id : est un identifiant unique qui représente le compte auquel le passkey est lié. Cet user.id est crucial car il est utilisé pour faire correspondre le passkey au compte de l'utilisateur.
• user.name et user.displayName : ce sont des métadonnées utilisées uniquement à des fins d'affichage dans l'interface utilisateur.

L'illustration suivante montre une structure de base de données simple et typique qui explique quelles informations seraient généralement stockées dans chaque champ :

Il est important de comprendre que même si user.name (souvent une adresse e-mail) et user.displayName (un nom plus convivial et lisible) aident l'utilisateur à identifier son compte dans l'interface de sélection, la véritable association entre un passkey et un compte est maintenue grâce à l'user.id et à l'ID de l'identifiant :

• Un compte peut avoir plusieurs passkeys, mais chaque passkey est identifié de manière unique et associé au compte à l'aide de l'user.id.
• Chaque passkey possède son propre ID de l'identifiant unique, généré par l'authentificateur.

Un problème se pose lorsque le user.name, qui peut être une adresse e-mail, change. Actuellement, il n'existe aucun mécanisme pour mettre à jour ce changement directement sur l'authentificateur côté client. Le user.name peut changer pour diverses raisons, par exemple lorsqu'un utilisateur met à jour son adresse e-mail. Malgré ce changement dans les métadonnées du compte côté serveur, l'ancien user.name continuera d'apparaître dans l'interface de sélection des identifiants, ce qui peut prêter à confusion pour les utilisateurs.

La solution de contournement pour ce problème consiste à créer un nouveau passkey avec le user.name mis à jour et le même user.id, puis à écraser le passkey existant. Cependant, cette approche est peu pratique pour plusieurs raisons :

1. Redondance : Chaque user.id ne peut avoir qu'un seul passkey par ID de partie de confiance, ce qui signifie que l'ancien passkey doit être remplacé par un nouveau, ce qui constitue une étape supplémentaire.
2. Expérience utilisateur : Les utilisateurs ne comprendront pas pourquoi ils doivent créer un nouveau passkey. C'est la raison pour laquelle cette solution de contournement n'est pas très répandue.
3. Complexité : Gérer la création et le remplacement de passkeys juste pour mettre à jour des métadonnées est une complexité inutile.

Les adresses e-mail, les numéros de téléphone et d'autres identifiants peuvent changer régulièrement. Sans une méthode simple pour mettre à jour directement user.name et user.displayName sur l'authentificateur, les utilisateurs risquent de rencontrer un problème persistant où ils voient et doivent sélectionner un passkey associé à leur ancienne adresse e-mail. Cette situation nuit à l'expérience fluide que les passkeys visent à offrir. L'API Signal WebAuthn a pour but de résoudre ce problème en permettant aux parties de confiance de signaler les mises à jour des métadonnées des passkeys sans nécessiter la création de nouveaux.

Avant d'expliquer comment mettre en œuvre l'API Signal, nous allons explorer le deuxième cas d'usage important qu'elle traite.

Become part of our Passkeys Community for updates & support.

Join

Un autre cas d'usage crucial est la suppression des passkeys sur l'authentificateur côté client. Au fil du temps, les utilisateurs peuvent révoquer des identifiants via la liste de gestion des passkeys ou supprimer leurs comptes, et il devient nécessaire de s'assurer que ces identifiants sont supprimés de l'authentificateur côté client pour éviter qu'ils n'apparaissent dans les futures interfaces de sélection d'identifiants (UI conditionnelle / remplissage automatique des passkeys).

Le besoin de cette fonctionnalité se présente dans plusieurs scénarios :

1. Passkey supprimé via les paramètres du compte : Lorsqu'un identifiant n'est plus valide, par exemple après qu'un utilisateur l'a explicitement supprimé via les paramètres de son compte :

Du point de vue de l'utilisateur, il est difficile de comprendre qu'une suppression dans les paramètres de son compte, dans une boîte de dialogue comme celle ci-dessus, n'entraîne pas la suppression du passkey sur ce client.

2. Suppression du compte : Lorsqu'un utilisateur supprime son compte, tous les passkeys associés devraient également être supprimés.
3. Politiques de sécurité : Les parties de confiance peuvent avoir des politiques de sécurité qui exigent la révocation des identifiants après des périodes d'inactivité ou en raison de problèmes de sécurité détectés.

Sans une méthode directe pour supprimer les passkeys côté client, ces identifiants obsolètes ou invalides continuent d'encombrer l'interface de sélection, ce qui entraîne de la confusion. Les utilisateurs pourraient voir et tenter d'utiliser des passkeys qui ne sont plus valides, ce qui se traduirait par des échecs d'authentification et une mauvaise expérience utilisateur.

La mise en œuvre de l'API Signal WebAuthn implique plusieurs étapes et considérations pour s'assurer que la fonctionnalité est intégrée correctement et en toute sécurité. L'API Signal permet aux parties de confiance (RP) de mettre à jour ou de supprimer des identifiants de passkey sur l'authentificateur côté client. Cette section décrit les principales considérations et étapes de la mise en œuvre.

Lors de la mise en œuvre de l'API Signal WebAuthn, il est crucial de garder à l'esprit les considérations suivantes :

• Protection de la vie privée : L'API Signal WebAuthn est conçue pour préserver la vie privée des utilisateurs, car c'est l'un des fondements de WebAuthn. Cela signifie qu'aucun retour n'est fourni à la RP pour savoir si le changement demandé a été traité. L'API fonctionne en silence pour éviter toute fuite potentielle d'informations sur l'état des identifiants.

• Disponibilité de l'authentificateur : L'efficacité de l'API Signal WebAuthn dépend de la disponibilité de l'authentificateur. Cela inclut à la fois la disponibilité physique (par exemple, la présence d'une clé de sécurité) et le support logiciel (par exemple, la compatibilité du navigateur et du système d'exploitation). Le navigateur ne peut effectuer des actions que si l'authentificateur est accessible et prend en charge les opérations nécessaires sans nécessiter d'authentification biométrique.

• Restrictions de domaine : L'API garantit que seule la partie de confiance associée à un domaine spécifique peut demander des modifications aux identifiants liés à ce domaine. Il s'agit d'une mesure de sécurité pour empêcher les modifications non autorisées par des tiers.

• L'ID de l'identifiant comme clé : Pour référencer les passkeys, l'ID de l'identifiant (Credential ID) est la clé principale utilisée par l'API Signal WebAuthn. Cet ID identifie de manière unique le passkey sur l'authentificateur côté client. L'API permet aux RP de modifier les métadonnées associées aux passkeys ou de signaler que certains passkeys ne doivent plus être accessibles, mais uniquement via l'ID de l'identifiant. Si un authentificateur ne connaît pas un ID de l'identifiant spécifique, il l'ignorera silencieusement.

Ces considérations sont essentielles pour comprendre les aspects les plus importants du bon fonctionnement de l'API Signal WebAuthn.

L'API Signal WebAuthn fournit un mécanisme simplifié pour que les parties de confiance (RP) puissent mettre à jour les métadonnées associées aux passkeys sur les authentificateurs côté client. Ceci est particulièrement important pour garantir que les utilisateurs voient des informations précises et à jour dans l'interface de sélection des identifiants sans avoir à créer de nouveaux passkeys inutilement. Voici comment l'API permet cela :

Mise à jour des métadonnées avec signalCurrentUserDetails(options)

La méthode signalCurrentUserDetails(options) de l'API Signal est spécifiquement conçue pour mettre à jour les métadonnées des passkeys. Cette méthode permet aux RP de fournir les valeurs actuelles pour user.name et user.displayName.

Voici comment le processus fonctionne (voir aussi la norme WebAuthn Niveau 3).

1. Structure de la méthode : La méthode signalCurrentUserDetails(options) inclut le rp.id, l'user.id et les valeurs mises à jour pour user.name et user.displayName.

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    name: "New user name",
    displayName: "New display name",
});

2. Mise à jour des métadonnées locales : L'authentificateur recherche les identifiants disponibles localement qui correspondent au rpId et à l'userId. Pour tous les identifiants correspondants, l'authentificateur mettra à jour le name et le displayName de l'identifiant.

3. Protection de la vie privée : Le processus est conçu pour préserver la vie privée. L'API Signal ne fournit aucun retour à la RP sur le succès des mises à jour, empêchant ainsi toute fuite d'informations sur l'état des identifiants.

4. Cohérence entre les appareils : En exécutant régulièrement les méthodes signalCurrentUserDetails(options), les RP peuvent s'assurer que les métadonnées des passkeys restent cohérentes sur les différents appareils et plateformes où l'utilisateur peut s'authentifier. Cette approche réduit les risques d'affichage d'informations obsolètes ou incorrectes dans l'interface de sélection des identifiants.

Dans la capture d'écran ci-dessus, vous pouvez voir comment Google Chrome signale une telle mise à jour à l'utilisateur. L'API Signal WebAuthn fait partie de Chrome 130 et peut être testée avec le Gestionnaire de mots de passe de Google sur ordinateur si le drapeau des fonctionnalités web expérimentales est activé.

L'API Signal WebAuthn fournit des mécanismes permettant aux parties de confiance (RP) de signaler la suppression de passkeys des authentificateurs côté client. Ceci est essentiel pour garantir que les identifiants obsolètes ou invalides n'apparaissent pas dans l'interface de sélection des identifiants, maintenant ainsi une expérience utilisateur simplifiée et sécurisée. Il existe deux méthodes pour supprimer les passkeys localement : signalUnknownCredential(options) et signalAllAcceptedCredentials(options). La première peut être utilisée dans des situations où l'utilisateur n'est pas authentifié, tandis que la seconde peut être utilisée lorsque l'utilisateur est authentifié. Par conséquent, cette dernière devrait être préférée pour des raisons de confidentialité.

Voici comment fonctionnent les deux méthodes :

1. Structure de la méthode : La méthode signalUnknownCredential(options) inclut le rpId (ID de la partie de confiance) et le credentialId (l'identifiant unique de l'identifiant à supprimer).

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // credential id the user just tried, base64url
});

2. Appel de la méthode : Les RP appellent cette méthode chaque fois qu'elles détectent qu'un identifiant doit être supprimé. Cela peut se produire immédiatement après une tentative d'authentification avec un identifiant invalide, lors de la suppression d'un compte, ou lorsqu'un utilisateur révoque un identifiant via les paramètres de son compte.

3. Gestion de la méthode : Lorsque la méthode signalUnknownCredential(options) est appelée, l'authentificateur côté client tente de trouver les identifiants qui correspondent au rpId et au credentialID spécifié pour les omettre. Selon les capacités de l'authentificateur, l'identifiant est supprimé ou une procédure spécifique à l'authentificateur est utilisée pour masquer l'identifiant lors des futures cérémonies d'authentification.

1. Structure de la méthode : La méthode signalAllAcceptedCredentials(options) inclut le rpId (ID de la partie de confiance), l'userId et une liste d'ID d'identifiants valides allAcceptedCredentialIds (liste des identifiants uniques des identifiants à conserver).

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    allAcceptedCredentialIds: ["bb"],
});

2. Appel de la méthode : Les RP appellent cette méthode chaque fois qu'elles détectent qu'un identifiant doit être supprimé et signalent une liste d'identifiants valides. Cette méthode doit être préférée à signalUnknownCredential(options) pour supprimer des identifiants.

3. Gestion de la méthode : Lorsque la méthode signalAllAcceptedCredentials(options) est appelée, l'authentificateur côté client fait correspondre le rpId et l'userId. L'authentificateur recherche tous les identifiants locaux qui correspondent au rpId et à l'userId. Le résultat est comparé à allAcceptedCredentialIds. S'il y a des identifiants locaux qui ne sont pas dans allAcceptedCredentialIds, alors ces identifiants sont supprimés localement (ou masqués selon l'authentificateur).

4. Afficher à nouveau les identifiants : Si des identifiants n'ont été que masqués (selon l'authentificateur) et font maintenant partie de allAcceptedCredentialIds, alors ces identifiants seront à nouveau présents dans les futures cérémonies d'authentification.

5. Conseils utiles :

   • Lors de l'utilisation de signalAllAcceptedCredentials(options), il est important de noter que les authentificateurs peuvent ne pas toujours être connectés au moment où cette méthode est exécutée. Par conséquent, les parties de confiance pourraient envisager d'exécuter signalAllAcceptedCredentials(options) périodiquement, par exemple à chaque connexion, pour s'assurer que tous les identifiants sont à jour.
   • Les parties de confiance doivent être prudentes lors de la spécification de la liste des ID d'identifiants (allAcceptedCredentialIds). Les identifiants qui ne sont pas inclus dans cette liste peuvent être masqués ou supprimés par l'authentificateur, potentiellement de manière irréversible. Pour éviter que des identifiants valides ne soient omis par erreur, il est crucial de s'assurer que la liste est complète. Si un ID d'identifiant valide est accidentellement oublié, il doit être ré-ajouté à signalAllAcceptedCredentials(options) dès que possible pour le rendre à nouveau visible, en supposant que l'authentificateur le permette.
   • Dans la mesure du possible, les authentificateurs devraient préférer masquer temporairement les identifiants plutôt que de les supprimer définitivement. Cette approche peut faciliter la récupération si un ID d'identifiant valide a été accidentellement omis par la partie de confiance, permettant de le restaurer sans perte permanente.

Dans la capture d'écran ci-dessus, vous pouvez voir comment Google Chrome signale les suppressions. L'API Signal WebAuthn fait partie de Chrome 132 et peut être testée avec le Gestionnaire de mots de passe de Google sur ordinateur.

Pour mettre en œuvre efficacement l'API Signal WebAuthn et assurer une synchronisation fluide des métadonnées des passkeys sur les authentificateurs côté client, tenez compte des recommandations suivantes :

• Suivez les mises à jour et l'implémentation réelle de l'API Signal WebAuthn : Restez informé des derniers développements et mises à jour liés à l'API Signal. L'API Signal WebAuthn est activée avec Google Chrome 132, et sera suivie par d'autres navigateurs (par exemple, Safari a également annoncé son support). Vérifiez régulièrement les progrès et les mises à jour de l'API Signal WebAuthn pour vous assurer que votre implémentation est conforme aux dernières normes et pratiques. Nous mettrons à jour cet article de blog à l'avenir ; il est actuellement basé sur les informations disponibles au 14 janvier 2025.
• Commencez par l'approche signalAllAcceptedCredentials(options) après chaque connexion réussie : Cette approche garantit que toutes les métadonnées et les ID d'identifiants sont mis à jour en une seule méthode, simplifiant le processus et maintenant la cohérence entre les appareils et les plateformes, tout en désactivant les identifiants supprimés ou obsolètes.
• Messagerie en temps réel avec signalUnknownCredential(options) pour les déploiements à grande échelle : Envisagez d'utiliser la messagerie en temps réel avec la méthode signalUnknownCredential(options) dans les déploiements à grande échelle ou lorsqu'il y a un besoin de mises à jour immédiates. Cette méthode peut améliorer l'efficacité et la précision de la gestion des identifiants, en veillant à ce que les identifiants invalides ou obsolètes soient rapidement supprimés de l'interface de sélection.

En suivant ces recommandations, vous pourrez mettre en œuvre efficacement l'API Signal WebAuthn dès qu'elle sera prise en charge, en vous assurant que les métadonnées des passkeys restent à jour et cohérentes sur tous les authentificateurs côté client, offrant ainsi une expérience utilisateur fluide et sécurisée pour les passkeys.

La norme WebAuthn évolue constamment, s'enrichissant de nouvelles fonctionnalités chaque mois. L'introduction de l'API Signal WebAuthn est une avancée significative dans la gestion des métadonnées et des suppressions de passkeys sur les authentificateurs côté client. Cette API répond aux cas d'usage cruciaux de synchronisation des informations entre les parties de confiance (RP) et les authentificateurs, et garantit que les passkeys invalides ou obsolètes sont supprimés, améliorant ainsi l'expérience utilisateur.

• Pourquoi l'API Signal est-elle nécessaire ? L'API Signal est essentielle pour mettre à jour les métadonnées des passkeys et supprimer les passkeys sur les authentificateurs côté client. Elle résout les problèmes liés aux informations user.name et user.displayName obsolètes, qui peuvent prêter à confusion lorsque les identifiants sont présentés dans l'interface de sélection. De plus, elle aide à maintenir une interface de sélection d'identifiants propre et sécurisée en supprimant les passkeys révoqués ou supprimés.
• Comment fonctionne l'API Signal ? L'API Signal fonctionne en permettant aux RP d'appeler des méthodes concernant l'état actuel des identifiants, y compris les mises à jour des métadonnées et la signalisation de la suppression des passkeys. Ces rapports sont traités par l'authentificateur côté client, garantissant que les informations présentées aux utilisateurs sont exactes et à jour. L'API est conçue pour préserver la vie privée et fonctionne sans fournir de retour à la RP sur le succès des mises à jour.

À mesure que la norme WebAuthn évolue, elle bénéficie des intérêts divers de ses participants, qui font progresser différentes parties de la norme. Il est crucial de garder un œil sur ces développements pour rester à jour avec les dernières améliorations et s'assurer que les implémentations restent alignées sur les meilleures pratiques et les normes les plus récentes. La communauté WebAuthn continue de stimuler l'innovation, rendant l'authentification plus sûre et plus conviviale.