So haben wir den Tab „WebAuthn“ in den Chrome-Entwicklertools erstellt

Fawaz Mohammad
Fawaz Mohammad
GitHub
Nina Satragno
Nina Satragno
X

Mit der Web Authentication API, auch WebAuthn genannt, können Server anstelle von Passwörtern die Public-Key-Kryptografie zur Registrierung und Authentifizierung von Nutzern verwenden. Dazu wird die Integration zwischen diesen Servern und starken Authentifikatoren ermöglicht. Diese Authentifikatoren können spezielle physische Geräte (z.B. Sicherheitsschlüssel) oder in Plattformen integriert sein (z.B. Fingerabdrucklesegeräte). Weitere Informationen zu WebAuthn finden Sie unter webauthn.guide.

Probleme von Entwicklern

Vor diesem Projekt gab es in Chrome keine native Unterstützung für die WebAuthn-Fehlerbehebung. Ein Entwickler, der eine App mit WebAuth erstellte, benötigte Zugriff auf physische Authentifikatoren. Das war aus zwei Gründen besonders schwierig:

  1. Es gibt viele verschiedene Arten von Authentifizierungsgeräten. Für die Fehlerbehebung bei den vielen Konfigurationen und Funktionen benötigte der Entwickler Zugriff auf viele verschiedene, manchmal teure Authentifikatoren.

  2. Physische Authentifizierungsgeräte sind von Grund auf sicher. Daher ist es in der Regel nicht möglich, ihren Status zu prüfen.

Wir wollten das vereinfachen und haben die Unterstützung für die Fehlerbehebung direkt in den Chrome-Entwicklertools hinzugefügt.

Lösung: neuer WebAuthn-Tab

Der Tab „WebAuthn“ in den DevTools erleichtert das Debuggen von WebAuthn erheblich, da Entwickler diese Authenticator emulieren, ihre Funktionen anpassen und ihren Status prüfen können.

Neuer WebAuthn-Tab

Implementierung

Die Fehlerbehebung für WebAuthn wurde in zwei Schritten hinzugefügt.

Zweiteiliger Prozess

Teil 1: WebAuthn-Domain dem Chrome-Entwicklertools-Protokoll hinzufügen

Zuerst haben wir eine neue Domain im Chrome DevTools Protocol (CDP) implementiert, die mit einem Handler verbunden ist, der mit dem WebAuthn-Backend kommuniziert.

Das CDP verbindet das DevTools-Frontend mit Chromium. In unserem Fall haben wir die WebAuthn-Domain-Akte verwendet, um eine Brücke zwischen dem WebAuthn-Tab in den DevTools und der WebAuthn-Implementierung von Chromium zu schlagen.

Über die WebAuthn-Domain können Sie die virtuelle Authenticator-Umgebung aktivieren und deaktivieren. Dadurch wird die Verbindung des Browsers zur echten Authenticator-Erkennung getrennt und stattdessen eine virtuelle Erkennung verwendet.

Außerdem stellen wir Methoden in der Domain bereit, die als dünne Schicht für die vorhandenen Virtual Authenticator- und Virtual Discovery-Schnittstellen dienen, die Teil der WebAuthn-Implementierung von Chromium sind. Dazu gehören das Hinzufügen und Entfernen von Authentifizierungsfaktoren sowie das Erstellen, Abrufen und Löschen der registrierten Anmeldedaten.

(Code lesen)

Teil 2: Nutzeroberfläche des Tabs erstellen

Zweitens haben wir einen Tab für Nutzer in der DevTools-Benutzeroberfläche erstellt. Der Tab besteht aus einer Ansicht und einem Modell. Ein automatisch generierter Agent verbindet die Domain mit dem Tab.

Es sind zwar drei Komponenten erforderlich, aber wir mussten uns nur um zwei davon kümmern: das Modell und die Ansicht. Die dritte Komponente – der Agent – wird nach dem Hinzufügen der Domain automatisch generiert. Kurz gesagt ist der Agent die Schicht, die die Aufrufe zwischen dem Front-End und der CDP weiterleitet.

Das Modell

Das Modell ist die JavaScript-Ebene, die den Kundenservicemitarbeiter mit der Ansicht verbindet. In unserem Fall ist das Modell recht einfach. Es nimmt Befehle aus der Ansicht auf, stellt die Anfragen so zusammen, dass sie von der CDP verwendet werden können, und sendet sie dann über den Agenten weiter. Diese Anfragen sind in der Regel einseitig und es werden keine Informationen an die Ansicht zurückgesendet.

Manchmal geben wir jedoch eine Antwort vom Modell zurück, um entweder eine ID für einen neu erstellten Authenticator anzugeben oder die in einem vorhandenen Authenticator gespeicherten Anmeldedaten zurückzugeben.

(Code lesen)

Die Ansicht

Neuer WebAuthn-Tab

Wir verwenden die Ansicht, um die Benutzeroberfläche bereitzustellen, die Entwickler beim Zugriff auf die DevTools sehen. Es enthält:

  1. Eine Symbolleiste zum Aktivieren der virtuellen Authenticator-Umgebung.
  2. Ein Bereich zum Hinzufügen von Authenticatorn.
  3. Ein Bereich für erstellte Authentifizierungsgeräte.

(Code lesen)

Symbolleiste zum Aktivieren der virtuellen Authenticator-Umgebung

Symbolleiste

Da die meisten Nutzerinteraktionen nicht mit dem gesamten Tab, sondern mit einem einzelnen Authenticator erfolgen, können Sie in der Symbolleiste nur die virtuelle Umgebung aktivieren und deaktivieren.

Warum ist das erforderlich? Es ist wichtig, dass der Nutzer die Umgebung explizit umschaltet, da dadurch die Verbindung des Browsers zur echten Authenticator Discovery getrennt wird. Wenn die Funktion aktiviert ist, werden angeschlossene physische Authentifizierungsfaktoren wie ein Fingerabdrucklesegerät daher nicht erkannt.

Wir haben uns dafür entschieden, dass eine explizite Ein-/Aus-Schaltfläche die Nutzerfreundlichkeit verbessert, insbesondere für Nutzer, die den Tab „WebAuthn“ aufrufen, ohne zu wissen, dass die automatische Erkennung deaktiviert ist.

Bereich „Authenticators“ hinzufügen

Bereich „Authenticators“ hinzufügen

Wenn die virtuelle Authenticator-Umgebung aktiviert wird, wird dem Entwickler ein Inline-Formular angezeigt, über das er einen virtuellen Authenticator hinzufügen kann. In diesem Formular können Nutzer das Protokoll und die Transportmethoden des Authenticators festlegen und festlegen, ob der Authenticator lokale Schlüssel und die Nutzerbestätigung unterstützt.

Sobald der Nutzer auf Hinzufügen klickt, werden diese Optionen gebündelt und an das Modell gesendet, das den Aufruf zum Erstellen eines Authenticators ausführt. Sobald dies abgeschlossen ist, erhält das Front-End eine Antwort und ändert dann die Benutzeroberfläche so, dass der neu erstellte Authenticator enthalten ist.

Authenticator-Ansicht

Authenticator-Ansicht

Jedes Mal, wenn ein Authenticator emuliert wird, fügen wir der Authenticator-Ansicht einen Abschnitt hinzu, um ihn darzustellen. Jeder Bereich für einen Authentifikator enthält einen Namen, eine ID, Konfigurationsoptionen, Schaltflächen zum Entfernen oder Aktivieren des Authentifikators und eine Anmeldedatentabelle.

Der Name des Authenticators

Der Name des Authenticators kann angepasst werden. Standardmäßig lautet er „Authenticator“, gefolgt von den letzten fünf Zeichen der ID. Ursprünglich war der Name des Authenticators seine vollständige ID und konnte nicht geändert werden. Wir haben anpassbare Namen implementiert, damit Nutzer den Authenticator anhand seiner Funktionen, des physischen Authenticators, den er emulieren soll, oder eines beliebigen Alias benennen können, der leichter zu merken ist als eine 36-stellige ID.

Tabelle „Anmeldedaten“

Wir haben jedem Abschnitt für Authenticator eine Tabelle hinzugefügt, in der alle Anmeldedaten aufgeführt sind, die mit einem Authenticator registriert wurden. In jeder Zeile finden Sie Informationen zu den Anmeldedaten sowie Schaltflächen zum Entfernen oder Exportieren der Anmeldedaten.

Derzeit erfassen wir die Informationen zum Ausfüllen dieser Tabellen, indem wir die CDP abfragen, um die registrierten Anmeldedaten für jeden Authenticator abzurufen. Wir planen, in Zukunft ein Ereignis für die Erstellung von Anmeldedaten hinzuzufügen.

Die Schaltfläche „Aktiv“

Außerdem haben wir jedem Abschnitt für Authentifikatoren das Optionsfeld Aktiv hinzugefügt. Der derzeit aktive Authenticator ist der einzige, der auf Anmeldedaten wartet und diese registriert. Ohne diese Funktion ist die Registrierung von Anmeldedaten mit mehreren Authenticatorn nicht deterministisch. Dies wäre ein fataler Fehler, wenn Sie versuchen, WebAuthn mit ihnen zu testen.

Wir haben den aktiven Status mit der Methode SetUserPresence auf virtuellen Authentifikatoren implementiert. Mit der Methode SetUserPresence wird festgelegt, ob Tests der Nutzerpräsenz für einen bestimmten Authenticator erfolgreich sind. Wenn wir sie deaktivieren, kann ein Authenticator nicht auf Anmeldedaten warten. Wenn wir also dafür sorgen, dass die Funktion für höchstens einen Authenticator (den als aktiv festgelegten) aktiviert und die Nutzerpräsenz für alle anderen deaktiviert ist, können wir ein deterministisches Verhalten erzwingen.

Eine interessante Herausforderung beim Hinzufügen der aktiven Schaltfläche bestand darin, eine Race-Bedingung zu vermeiden. Stellen Sie sich folgendes Szenario vor:

  1. Der Nutzer klickt für Authenticator X auf das Optionsfeld Aktiv und sendet eine Anfrage an die CDP, X als aktiv festzulegen. Das Optionsfeld Aktiv für X ist ausgewählt und alle anderen sind deaktiviert.

  2. Unmittelbar danach klickt der Nutzer auf das Optionsfeld Aktiv für Authenticator Y und sendet eine Anfrage an die CDP, Y als aktiv festzulegen. Das Optionsfeld Aktiv für Y ist ausgewählt und alle anderen, einschließlich für X, sind deaktiviert.

  3. Im Backend wird der Aufruf, Y als aktiv festzulegen, abgeschlossen und gelöst. Y ist jetzt aktiv und alle anderen Authentifikatoren sind es nicht.

  4. Im Backend wird der Aufruf zum Festlegen von X als aktiv abgeschlossen und aufgelöst. X ist jetzt aktiv und alle anderen Authentifikatoren, einschließlich Y, sind inaktiv.

Die Situation ist jetzt so: X ist der aktive Authenticator. Das Optionsfeld Aktiv für X ist jedoch nicht ausgewählt. Y ist nicht der aktive Authenticator. Das Optionsfeld Aktiv für „Ja“ ist jedoch ausgewählt. Der Status der Authenticator im Frontend stimmt nicht mit dem tatsächlichen Status überein. Das ist natürlich ein Problem.

Unsere Lösung: Pseudo-Zweier-Kommunikation zwischen den Optionsschaltflächen und dem aktiven Authenticator herstellen. Zuerst pflegen wir in der Ansicht eine Variable activeId, um die ID des aktuell aktiven Authenticators im Blick zu behalten. Dann warten wir, bis der Aufruf zum Aktivieren eines Authenticators zurückgegeben wird, und setzen activeId auf die ID dieses Authenticators. Zum Schluss durchlaufen wir jeden Abschnitt für Authenticator. Wenn die ID dieses Abschnitts activeId entspricht, setzen wir die Schaltfläche auf „Ausgewählt“. Andernfalls wird die Schaltfläche deaktiviert.

Das sieht dann so aus:


 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;
 }

Nutzungsmesswerte

Wir wollten die Nutzung dieser Funktion beobachten. Ursprünglich haben wir zwei Optionen entwickelt.

  1. Zählt jedes Mal, wenn der Tab „WebAuthn“ in den Entwicklertools geöffnet wurde. Diese Option kann zu einer Überzählung führen, da ein Nutzer den Tab öffnen kann, ohne ihn tatsächlich zu verwenden.

  2. Überwachen, wie oft das Kästchen „Virtuelle Authenticator-Umgebung aktivieren“ in der Symbolleiste aktiviert wurde Bei dieser Option kam es außerdem zu einer möglichen Überzählung, da einige Nutzer die Umgebung in derselben Sitzung mehrmals aktivieren und deaktivieren können.

Letztendlich haben wir uns für Letzteres entschieden, aber die Zählung durch eine Prüfung eingeschränkt, ob die Umgebung in der Sitzung bereits aktiviert war. Daher erhöhen wir die Anzahl nur um 1, unabhängig davon, wie oft der Entwickler die Umgebung gewechselt hat. Das funktioniert, weil jedes Mal, wenn der Tab wieder geöffnet wird, eine neue Sitzung erstellt wird. Dadurch wird die Prüfung zurückgesetzt und der Messwert kann wieder erhöht werden.

Zusammenfassung

Vielen Dank fürs Lesen. Wenn Sie Verbesserungsvorschläge für den Tab „WebAuthn“ haben, können Sie uns einen Fehler melden.

Hier finden Sie einige Ressourcen, wenn Sie mehr über WebAuthn erfahren möchten:

Vorschaukanäle herunterladen

Verwenden Sie als Standard-Entwicklungsbrowser Chrome Canary, Chrome Dev oder Chrome Beta. Diese Vorabversionen bieten Zugriff auf die neuesten DevTools-Funktionen, ermöglichen den Test moderner Webplattform-APIs und helfen Ihnen, Probleme auf Ihrer Website zu finden, bevor Ihre Nutzer sie bemerken.

Chrome-Entwicklertools-Team kontaktieren

Mit den folgenden Optionen können Sie über neue Funktionen, Updates oder andere Themen im Zusammenhang mit den DevTools sprechen.