Assurer la cohérence des clés d'accès avec les identifiants sur votre serveur avec l'API Signal

Eiji Kitamura

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 sur ordinateur est compatible avec l'API Signal à partir de Chrome 132. Le Gestionnaire de mots de passe de Google peut mettre à jour les clés d'accès en fonction du signal. Pour les fournisseurs de clés d'accès basés sur des extensions Chrome, c'est à eux de décider s'ils reflètent ou non le signal.

La compatibilité avec Chrome sur Android sera disponible ultérieurement.

Safari est compatible, mais pas encore implémenté. Firefox n'a pas encore partagé son avis.

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. Enregistrer le nom d'utilisateur et le nom à afficher aide l'utilisateur à identifier la clé d'accès à utiliser pour se connecter lorsqu'il y est invité. Cela est particulièrement utile lorsqu'ils 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, laissant la clé d'accès intacte 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, celle-ci lui sera toujours présentée par le fournisseur de clés d'accès. Toutefois, la tentative de connexion échouera, car le serveur ne pourra pas effectuer la validation avec 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 problèmes en permettant aux RP 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 : Signaler un nom d'utilisateur et/ou un nom à afficher mis à jour

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. Il appartient au fournisseur de clé d'accès de décider comment traiter ce signal, mais la clé d'accès associée doit être supprimée afin que l'utilisateur ne se connecte pas avec une clé d'accès, car l'identifiant associé n'existe pas.

Cette API peut être appelée lorsqu'une connexion basée sur une clé d'accès a échoué en raison de l'absence d'identifiant. De cette façon, le RP peut empêcher l'utilisateur de tenter de se connecter avec une clé d'accès qui n'est associée à aucun identifiant. Contrairement à signalAllAcceptedCredentials, cette méthode ne nécessite pas de transmettre la liste complète des ID d'identifiants. Elle doit donc être utilisée 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",
      ...
    ]
  });
}

En appelant PublicKeyCredential.signalAllAcceptedCredentials() avec un ID de RP, un ID utilisateur et une liste d'ID d'identifiants stockés, le RP peut informer le fournisseur de clés d'accès des identifiants restants dans son stockage. Il appartient au fournisseur de clés d'accès de décider comment traiter ce signal, mais les clés d'accès qui ne correspondent pas à cette liste devraient être supprimées afin que l'utilisateur ne voie pas de clés d'accès lors de la connexion pour lesquelles l'identifiant associé n'existe pas.

Cette API doit être appelée lorsqu'un utilisateur supprime une clé d'accès sur la partie de confiance et à chaque connexion, afin que le fournisseur de clés d'accès puisse conserver une liste synchronisée des 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. Il appartient au fournisseur de clés d'accès de traiter ce signal, mais les clés d'accès appartenant à l'utilisateur doivent être mises à jour avec les nouvelles informations utilisateur.

Cette API peut être appelée lorsque le nom d'utilisateur ou le nom à afficher de l'utilisateur sont modifiés, et à chaque connexion, afin que le fournisseur de clés d'accès puisse synchroniser ces informations avec le serveur.

Résumé

L'API Signal vous aide à créer une meilleure expérience de clé d'accès en éliminant les risques d'échec de connexion inattendu. Avec l'API Signal, les parties de confiance peuvent signaler la liste des identifiants existants et leurs métadonnées, afin de 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, commencez par Connexion sans mot de passe avec des clés d'accès.