Comment nous avons créé l'onglet WebAuthn des outils pour les développeurs Chrome

Fawaz Mohammad
Fawaz Mohammad
Nina Satragno
Nina Satragno

L'API Web Authentication, également appelée WebAuthn, permet aux serveurs d'utiliser la cryptographie à clé publique, plutôt que des mots de passe, pour enregistrer et authentifier les utilisateurs. Pour ce faire, il permet l'intégration entre ces serveurs et des authentificateurs sécurisés. Ces authentificateurs peuvent être des appareils physiques dédiés (par exemple, des clés de sécurité) ou intégrés à des plates-formes (par exemple, des lecteurs d'empreintes digitales). Pour en savoir plus sur WebAuthn, consultez le site webauthn.guide.

Difficultés pour les développeurs

Avant ce projet, WebAuthn n'était pas compatible avec le débogage natif dans Chrome. Un développeur créant une application qui utilisait WebAuth avait besoin d'accéder à des authentificateurs physiques. Cela était particulièrement difficile pour deux raisons:

  1. Il existe de nombreux types d'authentificateurs. Pour déboguer l'étendue des configurations et des fonctionnalités, le développeur a dû accéder à de nombreux authentificateurs différents, parfois onéreux.

  2. Les authentificateurs physiques sont sécurisés, par nature. Par conséquent, inspecter leur état est généralement impossible.

Pour vous faciliter la tâche, nous avons ajouté une aide au débogage directement dans les outils pour les développeurs Chrome.

Solution: nouvel onglet WebAuthn

L'onglet "Outils de développement WebAuthn" facilite le débogage de WebAuthn en permettant aux développeurs d'émuler ces authentificateurs, de personnaliser leurs fonctionnalités et d'inspecter leurs états.

Nouvel onglet WebAuthn

Implémentation

L'ajout de la prise en charge du débogage pour WebAuthn était un processus en deux étapes.

Processus en deux étapes

Partie 1: Ajouter le domaine WebAuthn au protocole des outils pour les développeurs Chrome

Tout d'abord, nous avons implémenté un nouveau domaine dans le protocole Chrome DevTools (CDP) qui se connecte à un gestionnaire qui communique avec le backend WebAuthn.

La plate-forme de données client connecte l'interface des outils de développement à Chromium. Dans notre cas, nous avons utilisé le domaine WebAuthn pour faire le lien entre l'onglet "Outils de développement WebAuthn" et l'implémentation de WebAuthn dans Chromium.

Le domaine WebAuthn permet d'activer et de désactiver l'environnement Virtual Authenticator. Cela permet de déconnecter le navigateur du véritable service Authenticator Discovery et de se connecter à une découverte virtuelle à la place.

Nous présentons également des méthodes du domaine qui agissent comme une couche fine pour les interfaces Virtual Authenticator et Virtual Discovery existantes, qui font partie de l'implémentation WebAuthn de Chromium. Ces méthodes incluent l'ajout et la suppression d'authentificateurs, ainsi que la création, l'obtention et la suppression des identifiants enregistrés.

(Lisez le code.)

Partie 2: Créer l'onglet visible par l'utilisateur

Ensuite, nous avons créé un onglet visible par l'utilisateur dans l'interface DevTools. L'onglet se compose d'une vue et d'un modèle. Un agent généré automatiquement connecte le domaine à l'onglet.

Bien que trois composants soient nécessaires, seuls deux d'entre eux étaient nécessaires: le model et la model. Le troisième composant, l'agent, est généré automatiquement après l'ajout du domaine. En bref, l'agent représente la couche qui achemine les appels entre l'interface et la plate-forme de données client.

Le modèle

Le modèle est la couche JavaScript qui relie l'agent et la vue. Dans notre cas, le modèle est assez simple. Il extrait les commandes de la vue, crée les requêtes de sorte qu'elles puissent être utilisées par la CDP, puis les envoie via l'agent. Ces requêtes sont généralement unidirectionnelles sans qu'aucune information ne soit renvoyée à la vue.

Toutefois, nous transmettons parfois une réponse du modèle soit pour fournir un ID à un authentificateur nouvellement créé, soit pour renvoyer les identifiants stockés dans un authentificateur existant.

(Lisez le code.)

Vue

Nouvel onglet WebAuthn

Nous utilisons cet affichage pour fournir l'interface utilisateur que les développeurs peuvent trouver lorsqu'ils accèdent aux outils de développement. Il comprend :

  1. Barre d'outils permettant d'activer l'environnement d'authentification virtuel
  2. Une section dans laquelle ajouter des authentificateurs.
  3. Section pour les authentificateurs créés.

(Lisez le code.)

Barre d'outils permettant d'activer l'environnement d'authentification virtuel

toolbar

Étant donné que la plupart des interactions utilisateur se font avec un authentificateur à la fois plutôt qu'avec l'intégralité de l'onglet, la seule fonctionnalité que nous fournissons dans la barre d'outils consiste à activer et désactiver l'environnement virtuel.

Pourquoi est-ce nécessaire ? Il est important que l'utilisateur active ou désactive explicitement l'environnement, car cela déconnecte le navigateur de la véritable fonctionnalité de découverte Authenticator. Par conséquent, lorsque ce paramètre est activé, les authentificateurs physiques connectés, tels qu'un lecteur d'empreinte digitale, ne sont pas reconnus.

Nous avons décidé qu'un bouton d'activation explicite améliore l'expérience utilisateur, en particulier pour ceux qui se rendent dans l'onglet WebAuthn sans s'attendre à ce qu'une découverte réelle soit désactivée.

Ajouter la section "Authentificateurs"

Ajouter la section "Authentificateurs"

Lors de l'activation de l'environnement d'authentification virtuel, nous présentons au développeur un formulaire intégré qui lui permet d'ajouter un authentificateur virtuel. Dans ce formulaire, nous fournissons des options de personnalisation qui permettent à l'utilisateur de décider du protocole et des méthodes de transport de l'authentificateur, et de déterminer si l'authentificateur est compatible avec les clés résidentes et la validation de l'utilisateur.

Lorsque l'utilisateur clique sur Ajouter, ces options sont regroupées et envoyées au modèle qui effectue l'appel afin de créer un authentificateur. Une fois l'opération terminée, l'interface reçoit une réponse, puis modifie l'interface utilisateur pour inclure l'authentificateur nouvellement créé.

Vue Authenticator

Vue Authenticator

Chaque fois qu'un authentificateur est émulé, nous ajoutons une section à la vue de l'authentificateur pour le représenter. Chaque section consacrée à l'authentificateur comprend un nom, un identifiant, des options de configuration, des boutons permettant de supprimer l'authentificateur ou de l'activer, ainsi qu'un tableau d'identifiants.

Nom Authenticator

Le nom de l'authentificateur est personnalisable et est défini par défaut sur "Authenticator", concaténé avec les cinq derniers caractères de son identifiant. À l'origine, le nom de l'authentificateur était sa pièce d'identité complète et ne pouvait pas être modifié. Nous avons implémenté des noms personnalisables afin que l'utilisateur puisse attribuer un libellé à l'authentificateur en fonction de ses capacités, de l'authentificateur physique qu'il est censé émuler ou de tout surnom un peu plus facile à assimiler qu'un identifiant à 36 caractères.

Table des identifiants

Nous avons ajouté un tableau à chaque section d'authentificateur qui affiche tous les identifiants enregistrés par un authentificateur. Sur chaque ligne, nous fournissons des informations sur un justificatif d'identité, ainsi que des boutons pour le supprimer ou l'exporter.

Actuellement, nous recueillons les informations nécessaires pour remplir ces tables en interrogeant la CDP afin d'obtenir les identifiants enregistrés pour chaque authentificateur. Nous prévoyons d'ajouter un événement pour la création des identifiants à l'avenir.

Bouton "Actif"

Nous avons également ajouté une case d'option Actif dans chaque section de l'authentificateur. L'authentificateur actuellement défini est actif est le seul qui écoute et enregistre les identifiants. Sans cela, l'enregistrement des identifiants avec plusieurs authentificateurs n'est pas déterministe, ce qui serait une faille fatale lorsque vous essayeriez WebAuthn de les utiliser.

Nous avons implémenté l'état actif à l'aide de la méthode SetUserPresence sur les authentificateurs virtuels. La méthode SetUserPresence détermine si les tests de présence des utilisateurs réussissent pour un authentificateur donné. Si nous le désactivons, l'authentificateur ne pourra pas écouter les identifiants. Par conséquent, en nous assurant qu'il est activé au maximum pour un authentificateur (celui défini comme actif) et en désactivant la présence de l'utilisateur pour tous les autres, nous pouvons forcer un comportement déterministe.

Un défi intéressant que nous avons dû relever lors de l'ajout du bouton actif était d'éviter une condition de concurrence. Imaginez le scénario suivant :

  1. L'utilisateur clique sur la case d'option Actif pour Authenticator X, ce qui envoie une demande à la CDP pour définir X comme actif. La case d'option Actif pour X est sélectionnée. Toutes les autres sont désélectionnées.

  2. Immédiatement après, l'utilisateur clique sur la case d'option Active (Actif) pour Authenticator Y, envoyant une demande à la CDP pour définir Y comme actif. La case d'option Actif pour Y est sélectionnée et toutes les autres, y compris X, sont désélectionnées.

  3. Dans le backend, l'appel permettant de définir Y comme actif est terminé et résolu. Y est désormais actif, et tous les autres authentificateurs ne le sont plus.

  4. Dans le backend, l'appel visant à définir X comme actif est terminé et résolu. X est désormais actif et tous les autres authentificateurs, y compris Y, ne le sont plus.

La situation est la suivante: X est l'authentificateur actif. Toutefois, la case d'option Actif pour X n'est pas sélectionnée. Y n'est pas l'authentificateur actif. Cependant, la case d'option Actif pour Y est sélectionnée. Il existe un désaccord entre l'interface et l'état réel des authentificateurs. Évidemment, c'est un problème.

Notre solution: établir une communication pseudo bidirectionnelle entre les cases d'option et l'authentificateur actif. Tout d'abord, nous conservons une variable activeId dans la vue pour suivre l'ID de l'authentificateur actif. Ensuite, nous attendons l'appel pour définir un authentificateur actif pour renvoyer, puis nous définissons activeId sur l'ID de cet authentificateur. Enfin, nous passons en boucle chaque section de l'authentificateur. Si l'ID de cette section correspond à activeId, le bouton est sélectionné. Sinon, nous désactivons le bouton.

Le résultat se présente comme suit:


 async _setActiveAuthenticator(authenticatorId) {
   await this._clearActiveAuthenticator();
   await this._model.setAutomaticPresenceSimulation(authenticatorId, true);
   this._activeId = authenticatorId;
   this._updateActiveButtons();
 }
 
 _updateActiveButtons() {
   const authenticators = this._authenticatorsView.getElementsByClassName('authenticator-section');
   Array.from(authenticators).forEach(authenticator => {
     authenticator.querySelector('input.dt-radio-button').checked =
         authenticator.getAttribute('data-authenticator-id') === this._activeId;
   });
 }
 
 async _clearActiveAuthenticator() {
   if (this._activeId) {
     await this._model.setAutomaticPresenceSimulation(this._activeId, false);
   }
   this._activeId = null;
 }

Métriques d'utilisation

Nous voulions suivre l'utilisation de cette fonctionnalité. Au départ, nous avons proposé deux options.

  1. Comptabiliser chaque ouverture de l'onglet WebAuthn des outils de développement. Cette option peut entraîner un sur-comptage, car un utilisateur peut ouvrir l'onglet sans l'utiliser réellement.

  2. Vérifiez le nombre de fois où la case "Activer l'environnement d'authentification virtuel" a été activée dans la barre d'outils. Cette option présentait également un problème potentiel de sur-comptabilisation, car certains peuvent activer et désactiver l'environnement plusieurs fois au cours d'une même session.

Nous avons finalement opté pour ce dernier modèle, mais limitons la comptabilisation en vérifiant si l'environnement a déjà été activé dans la session. Par conséquent, nous n'augmenterions le nombre que de 1, quel que soit le nombre de fois où le développeur a activé/désactivé l'environnement. Cela fonctionne, car une session est créée chaque fois que l'onglet est rouvert, ce qui réinitialise la vérification et permet à la métrique d'être à nouveau incrémentée.

Résumé

Merci de votre attention. Si vous avez des suggestions pour améliorer l'onglet WebAuthn, n'hésitez pas à nous signaler un bug.

Voici quelques ressources si vous souhaitez en savoir plus sur WebAuthn:

Télécharger les canaux de prévisualisation

Nous vous conseillons d'utiliser Chrome Canary, Dev ou Beta comme navigateur de développement par défaut. Ces versions preview vous permettent d'accéder aux dernières fonctionnalités des outils de développement, de tester des API de pointe de plates-formes Web et de détecter les problèmes sur votre site avant même que vos utilisateurs ne le fassent.

Contacter l'équipe des outils pour les développeurs Chrome

Utilisez les options suivantes pour discuter des nouvelles fonctionnalités et des modifications dans le message, ou de tout autre sujet lié aux outils de développement.

  • Envoyez-nous une suggestion ou des commentaires via crbug.com.
  • Signalez un problème lié aux outils de développement en accédant à Plus d'options   More > Aide > Signaler un problème dans les outils de développement.
  • Envoyez un tweet à @ChromeDevTools.
  • Laissez des commentaires sur les nouveautés des outils de développement vidéos YouTube ou les vidéos YouTube de nos conseils sur les outils de développement.