Publié le 12 novembre 2024, dernière mise à jour le 29 novembre 2024
L'API WebAuthn Signal permet aux parties de confiance de signaler les identifiants existants aux fournisseurs de clés d'accès connectés. Ainsi, un fournisseur de clés d'accès compatible peut mettre à jour ou supprimer les clés d'accès incorrectes ou révoquées de son espace de stockage afin qu'elles ne soient plus proposées aux utilisateurs.
Compatibilité
Chrome est compatible avec l'API Signal sur toutes les plates-formes de bureau et sur Android.
Safari est compatible, mais pas encore implémenté. Firefox n'a pas encore donné son avis.
Le Gestionnaire de mots de passe de Google peut mettre à jour les clés d'accès pour refléter le signal. Les fournisseurs de clés d'accès basés sur les extensions Chrome pour ordinateur décident s'ils doivent refléter le signal.
Arrière-plan
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 (tel qu'un gestionnaire de mots de passe) avec la clé privée, tandis que l'identifiant de clé publique est enregistré sur le serveur de la partie de confiance. L'enregistrement du nom d'utilisateur et du nom à afficher permet aux utilisateurs d'identifier les clés d'accès proposées à utiliser pour se connecter lorsqu'ils y sont invités. Cela est particulièrement utile lorsque les utilisateurs disposent de plus de deux clés d'accès provenant de différents fournisseurs.
Toutefois, dans certains cas, des incohérences entre la liste des clés d'accès du fournisseur et celle des identifiants du serveur peuvent entraîner une certaine confusion.
Le premier cas se produit lorsqu'un utilisateur supprime un identifiant sur le serveur. La clé d'accès reste alors inchangée chez le fournisseur de clés d'accès. La prochaine fois que l'utilisateur tentera de se connecter avec une clé d'accès, le fournisseur de clé d'accès lui présentera toujours cette clé. Toutefois, la tentative de connexion échouera, car le serveur ne pourra pas valider la clé publique supprimée.
Le deuxième cas se produit lorsqu'un utilisateur modifie son nom d'utilisateur ou son nom à afficher sur le serveur. La prochaine fois que l'utilisateur tentera de se connecter, l'ancienne adresse e-mail et l'ancien nom à afficher continueront de s'afficher dans le fournisseur de clés d'accès, même s'ils ont été modifiés sur le serveur. Idéalement, ils doivent être synchronisés.
API Signal
L'API Signal est une API WebAuthn qui résout ces incohérences en permettant aux parties de confiance de signaler les modifications au fournisseur de clés d'accès. Il existe trois méthodes :
PublicKeyCredential.signalUnknownCredential: indique qu'un identifiant n'existe pas.PublicKeyCredential.signalAllAcceptedCredentials: signale une liste d'identifiants enregistrés.PublicKeyCredential.signalCurrentUserDetails: Nom d'utilisateur et nom à afficher mis à jour dans Signal
Signaler qu'un identifiant n'existe pas
const credential = await navigator.credentials.get({ ... });
const payload = credential.toJSON();
const result = await fetch('/login', { ... });
// Detect authentication failure due to lack of the credential
if (result.status === 404) {
// Feature detection
if (PublicKeyCredential.signalUnknownCredential) {
await PublicKeyCredential.signalUnknownCredential({
rpId: "example.com",
credentialId: "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA" // base64url encoded credential ID
});
} else {
// Encourage the user to delete the passkey from the password manager nevertheless.
...
}
}
En appelant PublicKeyCredential.signalUnknownCredential() avec un ID de RP et un ID d'identifiant, le RP peut informer le fournisseur de clés d'accès que l'identifiant spécifié a été supprimé ou n'existe pas. Le fournisseur de clés d'accès détermine comment gérer ce signal, mais la clé d'accès associée doit être supprimée afin que les utilisateurs n'essaient pas de se connecter avec une clé d'accès sans identifiant associé.
Cette API peut être appelée lorsqu'une connexion basée sur une clé d'accès a échoué, car un identifiant est absent.
De cette façon, le RP peut empêcher les utilisateurs de tenter de se connecter avec une clé d'accès qui n'est associée à aucun identifiant. Contrairement à signalAllAcceptedCredentials, cette méthode ne vous oblige pas à transmettre la liste complète des ID d'identifiants. Utilisez-la chaque fois que l'utilisateur n'est pas authentifié pour éviter de révéler le nombre de clés d'accès pour un utilisateur donné.
Signaler une liste d'identifiants enregistrés
// After a user deletes a passkey or a user is signed in.
// Feature detection
if (PublicKeyCredential.signalAllAcceptedCredentials) {
await PublicKeyCredential.signalAllAcceptedCredentials({
rpId: "example.com",
userId: "M2YPl-KGnA8", // base64url encoded user ID
allAcceptedCredentialIds: [ // A list of base64url encoded credential IDs
"vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA",
...
]
});
}
Utilisez PublicKeyCredential.signalAllAcceptedCredentials() après qu'un utilisateur s'est connecté ou a géré les paramètres de son compte. Vous fournissez une liste de tous les ID d'identifiants valides pour cet utilisateur. Le fournisseur de clés d'accès compare cette liste à son stockage local pour cette partie de confiance. Le fournisseur de clés d'accès marque comme "masquée" toute clé d'accès trouvée dans son espace de stockage qui ne figure pas dans la liste allAcceptedCredentialIds.
Le système ne propose plus ces clés d'accès masquées pour la connexion ou la saisie automatique, mais elles ne sont pas immédiatement supprimées définitivement, ce qui permet de les restaurer si nécessaire.
À l'inverse, le fournisseur de clés d'accès restaure les clés d'accès présentes dans allAcceptedCredentialIds et marquées comme "masquées".
Cela permet à votre site Web de restaurer les clés d'accès qui ont été masquées par erreur.
Appelez cette API lorsqu'un utilisateur supprime une clé d'accès sur le RP et à chaque connexion, afin que le fournisseur de clés d'accès puisse tenir à jour une liste synchronisée de clés d'accès.
Nom d'utilisateur et nom à afficher mis à jour dans Signal
// After a user updated their username and/or display name
// or a user is signed in.
// Feature detection
if (PublicKeyCredential.signalCurrentUserDetails) {
await PublicKeyCredential.signalCurrentUserDetails({
rpId: "example.com",
userId: "M2YPl-KGnA8", // base64url encoded user ID
name: "a.new.email.address@example.com", // username
displayName: "J. Doe"
});
} else {
}
En appelant PublicKeyCredential.signalCurrentUserDetails() avec un ID de RP, un ID utilisateur, un nom d'utilisateur et un nom à afficher, le RP peut informer le fournisseur de clés d'accès des informations utilisateur mises à jour. Le fournisseur de clés d'accès détermine comment gérer ce signal, mais il doit mettre à jour les clés d'accès appartenant à l'utilisateur avec les nouvelles informations utilisateur.
Cette API peut être appelée lorsque le nom d'utilisateur ou le nom à afficher de l'utilisateur sont mis à jour, et à chaque connexion, afin que le fournisseur de clés d'accès puisse maintenir ces informations synchronisées avec le serveur.
Résumé
L'API Signal vous aide à créer une meilleure expérience de clé d'accès en éliminant les échecs de connexion inattendus. L'API Signal permet aux parties de confiance de signaler la liste des identifiants existants et leurs métadonnées, afin de pouvoir synchroniser les clés d'accès sur le fournisseur de clés d'accès.
Pour en savoir plus sur les clés d'accès, consultez Se connecter sans mot de passe avec des clés d'accès.