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 des 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 webauthn.guide.
Difficultés des développeurs
Avant ce projet, WebAuthn ne proposait pas de débogage natif dans Chrome. Un développeur qui crée une application utilisant WebAuth avait besoin d'accéder à des authentificateurs physiques. Cela a été particulièrement difficile pour deux raisons:
Il existe de nombreux types d'authentificateurs. Pour déboguer l'étendue des configurations et des fonctionnalités, le développeur devait avoir accès à de nombreux authentificateurs différents, parfois coûteux.
Les authentificateurs physiques sont, par conception, sécurisés. Il est donc généralement impossible d'inspecter leur état.
Nous avons voulu faciliter ce processus en ajoutant la prise en charge du débogage directement dans les outils pour les développeurs Chrome.
Solution: un nouvel onglet WebAuthn
L'onglet des 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.
Implémentation
L'ajout de la prise en charge du débogage à WebAuthn s'est déroulé en deux étapes.
Partie 1: Ajouter un domaine WebAuthn au protocole Chrome DevTools
Tout d'abord, nous avons implémenté un nouveau domaine dans le protocole CDP (Chrome DevTools Protocol), qui s'associe à un gestionnaire qui communique avec le backend WebAuthn.
Le CDP connecte le front-end des outils pour les développeurs à Chromium. Dans notre cas, nous avons utilisé les actions de domaine WebAuthn pour établir un pont entre l'onglet WebAuthn DevTools et l'implémentation de WebAuthn par Chromium.
Le domaine WebAuthn permet d'activer et de désactiver l'environnement d'authentification virtuelle, qui déconnecte le navigateur de la véritable découverte de l'authentificateur et connecte à la place une découverte virtuelle.
Nous exposons également des méthodes dans le domaine qui servent de couche mince aux 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 de leurs identifiants enregistrés.
(Lisez le code.)
Partie 2: Créer l'onglet destiné à l'utilisateur
Deuxièmement, nous avons créé un onglet destiné aux utilisateurs dans le frontend DevTools. L'onglet est composé 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, nous n'avons eu à nous soucier que de deux d'entre eux: le modèle et la vue. Le troisième composant, l'agent, est généré automatiquement après l'ajout du domaine. En bref, l'agent est la couche qui transporte les appels entre l'interface utilisateur et le CDP.
Modèle
Le modèle est la couche JavaScript qui connecte l'agent et la vue. Dans notre cas, le modèle est assez simple. Il récupère les commandes de la vue, crée les requêtes de sorte qu'elles puissent être consommées par le CDP, puis les envoie via l'agent. Ces requêtes sont généralement unidirectionnelles et aucune information n'est renvoyée à la vue.
Toutefois, nous renvoyons parfois une réponse du modèle pour fournir un ID pour un nouvel authentificateur ou pour renvoyer les identifiants stockés dans un authentificateur existant.
(Lisez le code.)
Vue
Nous utilisons la vue pour fournir l'interface utilisateur que le développeur peut trouver lorsqu'il accède à DevTools. Il comprend :
- Barre d'outils permettant d'activer l'environnement d'authentification virtuelle.
- Section permettant d'ajouter des authentificateurs.
- Section des authentificateurs créés.
(Lisez le code.)
Barre d'outils pour activer l'environnement d'authentification virtuelle
Étant donné que la plupart des interactions utilisateur concernent un seul authentificateur à la fois plutôt que l'ensemble 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 explicitement l'environnement, car cela déconnecte le navigateur de la véritable découverte de l'Authentificateur. Par conséquent, lorsqu'il 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/de désactivation explicite améliorerait l'expérience utilisateur, en particulier pour ceux qui accèdent à l'onglet WebAuthn sans s'attendre à ce que la découverte réelle soit désactivée.
Ajouter la section "Authentificateurs"
Lorsque vous activez l'environnement d'authentification virtuelle, nous présentons au développeur un formulaire intégré qui lui permet d'ajouter un authentificateur virtuel. Ce formulaire propose des options de personnalisation qui permettent à l'utilisateur de choisir le protocole et les méthodes de transport de l'authentificateur, ainsi que de savoir si l'authentificateur est compatible avec les clés résidentes et la validation de l'utilisateur.
Une fois que l'utilisateur a cliqué sur Ajouter, ces options sont regroupées et envoyées au modèle qui effectue l'appel pour créer un authentificateur. Une fois cette opération terminée, le front-end reçoit une réponse, puis modifie l'UI pour inclure l'authentificateur nouvellement créé.
Vue Authenticator
Chaque fois qu'un authentificateur est émulé, nous ajoutons une section à la vue de l'authentificateur pour le représenter. Chaque section d'authentificateur comprend un nom, un ID, des options de configuration, des boutons permettant de supprimer l'authentificateur ou de le définir comme actif, ainsi qu'un tableau d'identifiants.
Nom de l'authentificateur
Le nom de l'authentificateur est personnalisable et, par défaut, est "Authentificateur" concaténé avec les cinq derniers caractères de son ID. À l'origine, le nom de l'authentificateur était son ID complet et ne pouvait pas être modifié. Nous avons implémenté des noms personnalisables afin que l'utilisateur puisse nommer l'authentificateur en fonction de ses fonctionnalités, de l'authentificateur physique qu'il est censé émuler ou de tout surnom plus facile à retenir qu'un ID de 36 caractères.
Tableau des identifiants
Nous avons ajouté un tableau à chaque section d'authentificateur qui affiche tous les identifiants enregistrés par un authentificateur. Chaque ligne contient des informations sur un identifiant, ainsi que des boutons permettant de le supprimer ou de l'exporter.
Actuellement, nous recueillons les informations nécessaires pour remplir ces tables en interrogeant le CDP afin d'obtenir les identifiants enregistrés pour chaque authentificateur. Nous prévoyons d'ajouter un événement pour la création d'identifiants à l'avenir.
Bouton "Actif"
Nous avons également ajouté une case d'option Actif à chaque section de l'authentificateur. L'authentificateur actuellement défini comme actif est le seul à écouter et à enregistrer les identifiants. Sans cela, l'enregistrement des identifiants avec plusieurs authentificateurs n'est pas déterministe, ce qui constituerait un défaut fatal lors de la tentative de test de WebAuthn.
Nous avons implémenté l'état actif à l'aide de la méthode SetUserPresence sur les authentificateurs virtuels. La méthode SetUserPresence indique si les tests de présence de l'utilisateur réussissent pour un authentificateur donné. Si nous la désactivons, un authentificateur ne pourra pas écouter les identifiants. Par conséquent, en veillant à ce qu'elle soit activée pour un seul 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.
Nous avons dû faire face à un défi intéressant lors de l'ajout du bouton actif : éviter une condition de concurrence. Imaginez le scénario suivant :
L'utilisateur clique sur le bouton radio Active pour Authenticator X, ce qui envoie une requête au CDP pour définir X comme actif. La case d'option Active pour X est sélectionnée, et toutes les autres sont désélectionnées.
Immédiatement après, l'utilisateur clique sur la case d'option Active pour l'authentificateur Y, envoyant une requête au CDP pour définir Y comme actif. La case d'option Active pour Y est sélectionnée, et toutes les autres, y compris pour X, sont désélectionnées.
Dans le backend, l'appel visant à définir Y comme actif est terminé et résolu. Y est désormais actif, et tous les autres authentificateurs ne le sont pas.
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 pas.
La situation est maintenant la suivante: X est l'authentificateur actif. Toutefois, la case d'option Active pour X n'est pas sélectionnée. Y n'est pas l'authentificateur actif. Toutefois, la case d'option Active pour Y est sélectionnée. Il existe un désaccord entre l'interface utilisateur et l'état réel des authentificateurs. Évidemment, c'est un problème.
Notre solution: établir une communication pseudo bidirectionnelle entre les boutons radio et l'authentificateur actif. Tout d'abord, nous maintenons une variable activeId dans la vue pour suivre l'ID de l'authentificateur actuellement actif. Nous attendons ensuite que l'appel permettant de définir un authentificateur actif renvoie une valeur, puis nous définissons activeId sur l'ID de cet authentificateur. Enfin, nous itérons sur chaque section de l'authentificateur. Si l'ID de cette section est égal à activeId, nous définissons le bouton sur "Sélectionné". Sinon, nous désélectionnons le bouton.
Voici à quoi cela ressemble:
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 souhaitions suivre l'utilisation de cette fonctionnalité. Au départ, nous avons imaginé deux options.
Compter chaque fois que l'onglet WebAuthn des outils pour les développeurs a été ouvert Cette option peut entraîner un surcomptage, car une personne peut ouvrir l'onglet sans l'utiliser.
Suivez le nombre de fois où la case "Activer l'environnement d'authentification virtuelle" de la barre d'outils a été activée. Cette option présentait également un problème de surcomptage potentiel, car certains utilisateurs peuvent activer et désactiver l'environnement plusieurs fois au cours d'une même session.
Nous avons finalement opté pour la seconde option, mais en limitant le comptage en vérifiant si l'environnement avait 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é l'environnement. Cela fonctionne, car une nouvelle 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 incrémentée à nouveau.
Résumé
Merci de votre attention. Si vous avez des suggestions pour améliorer l'onglet WebAuthn, n'hésitez pas à nous en faire part en envoyant un bug.
Voici quelques ressources pour en savoir plus sur WebAuthn:
- Document de conception du front-end des outils de développement WebAuthn
- Document de conception de l'API de test d'authentification Web
- Spécification de l'API Web Authentication (WebAuthn)
- Explication et guide WebAuthn
Télécharger les canaux de prévisualisation
Envisagez d'utiliser Chrome Canary, Dev ou Bêta comme navigateur de développement par défaut. Ces canaux de prévisualisation vous donnent accès aux dernières fonctionnalités de DevTools, vous permettent de tester les API de plates-formes Web de pointe et vous aident à détecter les problèmes sur votre site avant vos utilisateurs.
Contacter l'équipe des outils pour les développeurs Chrome
Utilisez les options suivantes pour discuter des nouvelles fonctionnalités, des mises à jour ou de tout autre élément lié aux outils pour les développeurs.
- Envoyez-nous vos commentaires et vos demandes de fonctionnalités sur crbug.com.
- Signalez un problème dans les outils de développement à l'aide de l'icône Plus d'options > Aide > Signaler un problème dans les outils de développement dans les outils de développement.
- Envoyez un tweet à @ChromeDevTools.
- Laissez des commentaires sur les vidéos YouTube sur les nouveautés des outils pour les développeurs ou sur les vidéos YouTube sur les conseils concernant les outils pour les développeurs.