Publié le 13 novembre 2024
À partir de Chrome 132, Chrome pour ordinateur (macOS, Windows, Linux et ChromeOS) est compatible avec l'API Signal, qui peut maintenir les clés d'accès sur les fournisseurs de clés d'accès cohérentes avec les identifiants de clé publique sur le serveur de la partie de confiance.
Lorsqu'une clé d'accès (identifiant détectable) est créée, des métadonnées telles qu'un nom d'utilisateur et un nom à afficher sont enregistrées auprès du fournisseur de clés d'accès (par exemple, un gestionnaire de mots de passe) avec la clé privée, et les identifiants de clé publique sont enregistrés sur le serveur de la partie de confiance (RP). L'enregistrement du nom d'utilisateur et du nom à afficher permet à l'utilisateur d'identifier la clé d'accès à utiliser pour se connecter, car il est invité à sélectionner une clé d'accès lors de la connexion. Cela est particulièrement utile lorsqu'il dispose de plus de deux clés d'accès provenant de différents fournisseurs.
Toutefois, dans certains cas, des différences entre la liste des clés d'accès sur le fournisseur de clés d'accès et la liste des identifiants sur le serveur peuvent prêter à confusion.
Le premier cas se produit lorsqu'un utilisateur supprime des identifiants sur le serveur, mais laisse la clé d'accès dans le fournisseur de clés d'accès. La prochaine fois que l'utilisateur tentera de se connecter avec la clé d'accès, le fournisseur de clés d'accès la lui présentera toujours. Toutefois, la tentative de connexion échouera, car le serveur ne pourra pas effectuer la validation avec la clé publique supprimée.
Le second cas se produit lorsqu'un utilisateur modifie son nom d'utilisateur ou son nom à afficher sur le serveur. La prochaine fois que l'utilisateur tente de se connecter, la clé d'accès du fournisseur de clés d'accès continue d'afficher l'ancien nom d'utilisateur et le nom à afficher, même s'ils ont été mis à jour sur le serveur. Idéalement, ils doivent être synchronisés.
API Signal
L'API WebAuthn Signal permet aux RP de signaler les identifiants existants aux fournisseurs de clés d'accès connectés. Cela permet à un fournisseur de clés d'accès compatible de mettre à jour ou de supprimer des clés d'accès incorrectes ou révoquées de son espace de stockage afin qu'il soit cohérent avec le serveur.
Par exemple, lorsqu'un utilisateur ne parvient pas à se connecter à un RP, car les identifiants associés sur le serveur du RP n'existent plus, le RP peut utiliser l'API Signal pour signaler au fournisseur de clés d'accès que les identifiants supprimés ne sont plus valides. Le fournisseur de clés d'accès peut alors supprimer la clé d'accès associée.
Par exemple, lorsqu'un utilisateur accède à la page des paramètres du RP et supprime les identifiants existants, le RP peut utiliser l'API Signal pour signaler une liste d'identifiants disponibles au fournisseur de clés d'accès afin que celui-ci puisse synchroniser les clés d'accès associées.
Il peut également indiquer un nom d'utilisateur et un nom à afficher mis à jour afin que les métadonnées de clé d'accès stockées pour le même utilisateur puissent être mises à jour.
Par exemple, lorsqu'un utilisateur met à jour son nom d'utilisateur ou son nom à afficher sur le RP, le RP peut utiliser l'API Signal pour signaler les informations utilisateur mises à jour au fournisseur de clés d'accès afin que le fournisseur de clés d'accès puisse synchroniser les informations utilisateur des clés d'accès associées.
Le Gestionnaire de mots de passe de Google sur Chrome pour ordinateur implémente l'API Signal. Pour les fournisseurs de clés d'accès basés sur des extensions Chrome, il leur appartient de refléter ou non le signal.
Nous prévoyons de prendre en charge l'API Signal sur Android Chrome à l'avenir.
Pour savoir comment intégrer l'API Signal WebAuthn, consultez Synchroniser la liste des clés d'accès avec le serveur à l'aide de l'API Signal.