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

Looking for a dev-focused passkey reference? Download our Passkeys Cheat Sheet. Trusted by dev teams at Ally, Stanford CS & more.

Get Cheat Sheet

Dernière mise à jour : 4 novembre 2025

Voici un aperçu rapide du support de l'API Signal WebAuthn sur les différentes plateformes :

⚠️ Problème connu : Safari 26+ présente un bug où la promesse ne se résout pas correctement (WebKit Bug #298951). Un correctif est en attente de fusion.

L'écosystème des passkeys est en pleine mutation. Pour faciliter ce changement, le standard sous-jacent WebAuthn évolue rapidement. Les nouvelles fonctionnalités débutent souvent par une explication technique sur GitHub, puis se transforment en "pull request" dans le standard une fois qu'elles ont été suffisamment débattues. Récemment, cette pull request a été ajoutée au projet de standard sous le nom d'API Signal WebAuthn.

Dans cet article, nous allons voir :

• Pourquoi l'API Signal WebAuthn est nécessaire : Quels cas d'usage l'API supporte-t-elle ?
• Comment fonctionne l'API Signal WebAuthn : Comment fonctionne-t-elle concrètement ? Quelles sont les recommandations pour les Relying Parties ?

Au moment où nous écrivons ces lignes, l'API Signal WebAuthn est activée par défaut depuis Chrome 132. Elle était auparavant connue sous le nom de Reporting API avant d'être renommée pour éviter tout conflit avec une autre API du même nom.

L'API Signal WebAuthn répond à des besoins spécifiques liés à la gestion des passkeys côté client. Concrètement, elle aide à garder les informations synchronisées entre la Relying Party (RP) et les authentificateurs intégrés aux systèmes d'exploitation clients. Voici les cas d'usage importants :

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Lorsqu'un passkey est créé, il inclut plusieurs informations : user.id, user.name et user.displayName. Le passkey lui-même est identifié via un Credential ID unique.

• user.id : est un identifiant unique qui représente le compte auquel le passkey est lié. Ce user.id est crucial car il est utilisé pour faire correspondre le passkey au compte 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 quelle information serait habituellement stockée dans quel champ :

Il est important de comprendre que bien que le user.name (souvent une adresse e-mail) et le 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 via le user.id et le Credential ID :

• Un compte peut avoir plusieurs passkeys, mais chaque passkey est identifié de manière unique et lié au compte via le user.id.
• Chaque passkey possède lui-même un Credential ID unique généré par l'authentificateur.

Un problème survient lorsque le user.name, qui peut être une adresse e-mail, change. Actuellement, il n'existe aucun mécanisme pour répercuter ce changement directement sur l'authentificateur côté client. Le user.name peut changer pour diverses raisons, comme 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.

La solution de contournement actuelle 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 : Un authentificateur ne peut stocker qu'un seul passkey par user.id pour un ID de Relying Party spécifique. Cela signifie que l'ancien passkey doit être remplacé par un nouveau pour mettre à jour les métadonnées, ce qui représente une étape supplémentaire.
2. Expérience Utilisateur : Les utilisateurs ne comprendront pas pourquoi ils doivent créer un nouveau passkey. C'est pourquoi cette solution n'est pas très répandue.
3. Complexité : Gérer la création de passkeys et leur remplacement uniquement pour mettre à jour des métadonnées ajoute une complexité inutile.

Les adresses e-mail, numéros de téléphone et autres identifiants peuvent changer régulièrement. Sans une méthode simple pour mettre à jour user.name et user.displayName directement 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 sont censés offrir. L'API Signal WebAuthn vise à résoudre ce problème en permettant aux Relying Parties de signaler les mises à jour des métadonnées des passkeys sans nécessiter la création de nouveaux passkeys. Avant d'expliquer comment implémenter l'API Signal, explorons le second cas d'usage important qu'elle adresse.

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 leur liste de gestion de passkeys ou supprimer leurs comptes. Il devient alors nécessaire de s'assurer que ces identifiants sont retirés de l'authentificateur client pour éviter qu'ils n'apparaissent dans les futures interfaces de sélection (Conditional UI / remplissage automatique des passkeys).

Le besoin pour 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 ses paramètres de compte :

Du point de vue de l'utilisateur, il est difficile de comprendre qu'une suppression dans les paramètres de son compte, via une fenêtre comme celle ci-dessus, n'entraîne pas la suppression du passkey sur ce client spécifique.

2. Suppression de compte : Lorsqu'un utilisateur supprime son compte, tous les passkeys associés devraient également être supprimés.

3. Politiques de sécurité : Les Relying Parties peuvent avoir des politiques de sécurité exigeant la révocation des identifiants après des périodes d'inactivité ou suite à la détection de problèmes de sécurité.

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

Regardez cette vidéo pour voir comment supprimer des passkeys côté serveur dans la console de gestion Corbado Connect :

L'implémentation de l'API Signal WebAuthn implique plusieurs étapes et considérations pour s'assurer que la fonctionnalité est intégrée correctement et de manière sécurisée. L'API Signal permet aux Relying Parties (RPs) de mettre à jour ou de supprimer des passkeys sur l'authentificateur côté client. Cette section détaille les points clés et les étapes de mise en œuvre.

Lors de l'implémentation de l'API Signal WebAuthn, il est crucial de garder à l'esprit les considérations suivantes :

• Respect de la vie privée : L'API Signal WebAuthn est conçue pour préserver la confidentialité des utilisateurs, qui est l'un des fondements de WebAuthn. Cela signifie qu'aucun retour n'est fourni à la RP pour indiquer si le changement demandé a été traité. L'API opère silencieusement 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 et le support logiciel (par exemple, compatibilité du navigateur et du système d'exploitation). Le navigateur ne peut effectuer des actions que si l'authentificateur est accessible et supporte les opérations nécessaires sans requérir d'authentification biométrique.

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

• Credential ID comme clé : Lorsqu'on fait référence à des passkeys, le Credential ID est la clé primaire utilisée par l'API Signal WebAuthn. Cet ID identifie de manière unique le passkey sur l'authentificateur client. L'API permet aux RPs de changer les métadonnées associées aux passkeys ou de signaler que certains passkeys ne devraient plus être accessibles, mais uniquement via le Credential ID. Si un authentificateur ne connaît pas un Credential ID spécifique, il l'ignorera silencieusement.

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

L'API Signal WebAuthn fournit un mécanisme simplifié pour permettre aux Relying Parties (RPs) de mettre à jour les métadonnées associées aux passkeys sur les authentificateurs clients. C'est particulièrement important pour s'assurer 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 RPs de fournir les valeurs actuelles pour user.name et user.displayName.

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

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

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "aabbcc", // identifiant utilisateur, base64url.
    name: "Nouveau nom utilisateur",
    displayName: "Nouveau nom affiché",
});

2. Mise à jour des métadonnées locales : Le système recherche les identifiants disponibles localement (sur l'authentificateur) qui correspondent au rpId et au userId. Pour tous les identifiants correspondants, l'authentificateur mettra à jour le name et le displayName.

3. Respect de la vie privée : Le processus est conçu pour préserver la confidentialité. L'API Signal ne fournit aucun retour à la RP sur le succès du traitement des mises à jour, empêchant 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 RPs peuvent s'assurer que les métadonnées des passkeys restent cohérentes sur les différents appareils et plateformes où l'utilisateur s'authentifie. Cette approche réduit les risques d'afficher des informations obsolètes ou incorrectes dans l'interface de sélection.

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 et peut être testée avec le Gestionnaire de mots de passe Google sur ordinateur.

L'API Signal WebAuthn fournit des mécanismes aux Relying Parties (RPs) pour signaler la suppression de passkeys des authentificateurs clients. C'est essentiel pour s'assurer que les identifiants obsolètes ou invalides n'apparaissent pas dans l'interface de sélection, maintenant ainsi une expérience utilisateur fluide 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 lorsque 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 privilégié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 Relying Party) et le credentialId (l'identifiant unique de l'identifiant à supprimer).

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // id de l'identifiant que l'utilisateur vient d'essayer, base64url
});

2. Appel de la méthode : Les RPs appellent cette méthode chaque fois qu'elles détectent qu'un identifiant doit être supprimé. Cela peut être 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. Traitement de la méthode : Lorsque la méthode signalUnknownCredential(options) est appelée, l'authentificateur client essaie de trouver les identifiants qui correspondent au rpId et au credentialID spécifié pour l'omission. Selon les capacités de l'authentificateur, l'identifiant est supprimé ou une procédure spécifique à l'authentificateur pour masquer l'identifiant dans les futures cérémonies d'authentification est employée.

1. Structure de la méthode : La méthode signalAllAcceptedCredentials(options) inclut le rpId (ID de la Relying Party), le userId et une liste d'identifiants valides allAcceptedCredentialIds (liste des identifiants uniques des passkeys qui doivent être conservés).

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

2. Appel de la méthode : Les RPs appellent cette méthode lorsqu'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. Traitement de la méthode : Lorsque la méthode signalAllAcceptedCredentials(options) est appelée, l'authentificateur client fait correspondre le rpId et le userId. L'authentificateur recherche alors tous les identifiants locaux correspondant à ces IDs. Le résultat est comparé à allAcceptedCredentialIds. S'il existe des identifiants locaux qui ne figurent pas dans allAcceptedCredentialIds, alors ces identifiants sont supprimés localement (ou masqués selon l'authentificateur).

4. Réafficher les identifiants : Si des identifiants ont seulement été masqués (selon l'authentificateur) et font à nouveau partie de allAcceptedCredentialIds, alors ces identifiants seront de nouveau présents lors des 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 Relying Parties devraient envisager d'exécuter signalAllAcceptedCredentials(options) périodiquement, comme lors de chaque connexion, pour s'assurer que tous les identifiants sont à jour.
   • Les Relying Parties doivent être prudentes lorsqu'elles spécifient la liste des IDs 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 laissé de côté, il doit être rajouté à signalAllAcceptedCredentials(options) dès que possible pour le rendre à nouveau visible, en supposant que l'authentificateur le supporte.
   • Dans la mesure du possible, les authentificateurs devraient préférer masquer temporairement les identifiants au lieu 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 Relying Party, 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 peut être testée avec le Gestionnaire de mots de passe Google sur ordinateur.

Pour implémenter efficacement l'API Signal WebAuthn et assurer une synchronisation fluide des métadonnées des passkeys sur les authentificateurs clients, prenez en compte les recommandations suivantes :

• Surveillez les mises à jour et l'implémentation actuelle 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, suivi par d'autres navigateurs (par exemple Safari a également annoncé son support). Vérifiez régulièrement les progrès et mises à jour de l'API Signal WebAuthn pour vous assurer que votre implémentation s'aligne sur les derniers standards et pratiques. Nous mettrons à jour cet article de blog au fur et à mesure que le paysage évolue.
• Commencez par l'approche signalAllAcceptedCredentials(options) après chaque connexion réussie : Cette approche garantit que toutes les métadonnées et les IDs d'identifiants sont mis à jour en une seule méthode, simplifiant le processus et maintenant la cohérence entre les appareils et 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) pour 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, garantissant que les identifiants invalides ou obsolètes sont rapidement retirés de l'interface de sélection.

En suivant ces recommandations, vous pourrez implémenter l'API Signal WebAuthn efficacement dès qu'elle sera supportée, garantissant que les métadonnées des passkeys restent à jour et cohérentes sur tous les authentificateurs clients, offrant ainsi une expérience utilisateur fluide et sécurisée pour les passkeys.

Le standard WebAuthn évolue continuellement, s'enrichissant de nouvelles fonctionnalités mois après mois. L'introduction de l'API Signal WebAuthn est une étape significative dans la gestion des métadonnées et des suppressions de passkeys sur les authentificateurs clients. Cette API répond aux cas d'usage cruciaux de synchronisation des informations entre les Relying Parties (RPs) 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 clients. Elle résout les problèmes liés aux informations user.name et user.displayName obsolètes, qui peuvent causer de la confusion lorsque les identifiants sont présentés dans l'interface de sélection. De plus, elle aide à maintenir une interface de sélection propre et sécurisée en supprimant les passkeys révoqués ou effacés.
• Comment fonctionne l'API Signal ? L'API Signal fonctionne en permettant aux RPs d'appeler des méthodes concernant l'état actuel des identifiants, incluant les mises à jour des métadonnées et le signalement de la suppression de passkeys. Ces rapports sont traités par l'authentificateur client, garantissant que les informations présentées aux utilisateurs sont exactes et à jour. L'API est conçue pour respecter la vie privée et opère sans fournir de retour à la RP sur le succès des mises à jour.

À mesure que le standard WebAuthn évolue, il bénéficie des intérêts divers de ses participants, qui font avancer différentes parties du standard. Garder un œil sur ces développements est crucial pour rester à jour avec les dernières améliorations et s'assurer que les implémentations restent alignées avec les meilleures pratiques et standards actuels. La communauté WebAuthn continue de stimuler l'innovation, rendant l'authentification plus sécurisée et conviviale.