Mithilfe der Web Authentication API, die auch WebAuthn genannt wird, können Server anstelle von Passwörtern Public-Key-Kryptografie verwenden, um Nutzer zu registrieren und zu authentifizieren. Dies erfolgt durch die Aktivierung der Integration zwischen diesen Servern und starken Authenticators. Bei diesen Authenticatoren kann es sich um dedizierte physische Geräte (z.B. Sicherheitsschlüssel) oder um integrierte Plattformen (z.B. Fingerabdruckleser) handeln. Weitere Informationen zu WebAuthn finden Sie unter webauthn.guide.
Probleme von Entwicklern
Vor diesem Projekt hatte WebAuthn keinen nativen Support für das Debugging in Chrome. Ein Entwickler, der eine App entwickelt hat, die WebAuth nutzt, benötigte Zugriff auf physische Authenticators. Dies war aus zwei Gründen besonders schwierig:
Es gibt viele verschiedene Geschmacksrichtungen von Authenticatoren. Um die Bandbreite der Konfigurationen und Funktionen zu debuggen, musste der Entwickler Zugriff auf viele verschiedene, manchmal teure Authenticatoren haben.
Physische Authenticatoren sind von Grund auf sicher. Daher ist es normalerweise unmöglich, ihren Status zu überprüfen.
Um dies zu vereinfachen, haben wir die Unterstützung für die Fehlerbehebung direkt in den Chrome-Entwicklertools hinzugefügt.
Lösung: Neuer WebAuthn-Tab
Der Tab WebAuthn DevTools erleichtert die Fehlerbehebung bei WebAuthn erheblich, da Entwickler diese Authenticatoren emulieren, ihre Funktionen anpassen und ihren Status prüfen können.
Implementierung
Das Hinzufügen der Unterstützung für die Fehlerbehebung zu WebAuthn war ein zweiteiliger Prozess.
Teil 1: WebAuthn-Domain zum Chrome-DevTools-Protokoll hinzufügen
Zuerst haben wir im Chrome DevTools Protocol (CDP) eine neue Domain implementiert, die in einen Handler eingebunden wird, der mit dem WebAuthn-Back-End kommuniziert.
Das CDP verbindet das Front-End der Entwicklertools mit Chromium. In unserem Fall nutzten wir die WebAuthn-Domain, um eine Brücke zwischen dem Tab „WebAuthn DevTools“ und der WebAuthn-Implementierung in Chromium zu schlagen.
Die WebAuthn-Domain ermöglicht das Aktivieren und Deaktivieren der Virtual Authenticator Environment, wodurch der Browser von der echten Authenticator Discovery getrennt und stattdessen eine Virtual Authenticator Discovery angeschlossen wird.
Außerdem stellen wir Methoden in der Domain zur Verfügung, die als schlanke Schicht für die vorhandenen Virtual Authenticator- und Virtual Discovery-Oberflächen fungieren, die Teil der WebAuthn-Implementierung von Chromium sind. Zu diesen Methoden gehören das Hinzufügen und Entfernen von Authenticators sowie das Erstellen, Abrufen und Löschen ihrer registrierten Anmeldedaten.
(Code lesen)
Teil 2: Erstellen des Tabs für Nutzer
Dann haben wir im Front-End der Entwicklertools einen Tab für Nutzer erstellt. Der Tab besteht aus einer Ansicht und einem Modell. Ein automatisch generierter Agent verbindet die Domain mit dem Tab.
Es werden zwar drei erforderliche Komponenten benötigt, aber wir mussten uns nur um zwei kümmern: das model und die model. Die dritte Komponente – der Agent – wird nach dem Hinzufügen der Domain automatisch generiert. Kurz gesagt ist der Agent die Ebene, die die Aufrufe zwischen dem Front-End und dem CDP überträgt.
Das Modell
Das Modell ist die JavaScript-Ebene, die den Agent und die Ansicht verbindet. In unserem Fall ist das Modell ziemlich einfach. Es übernimmt Befehle aus der Ansicht, erstellt die Anfragen so, dass sie vom CDP verarbeitet werden können, und sendet sie dann über den Agent. Diese Anfragen erfolgen normalerweise in eine Richtung, wobei keine Informationen an die Ansicht zurückgesendet werden.
Manchmal geben wir jedoch eine Antwort vom Modell zurück, um entweder eine ID für einen neu erstellten Authenticator oder die in einem vorhandenen Authenticator gespeicherten Anmeldedaten zurückzugeben.
(Code lesen)
Die Ansicht
Wir verwenden die Datenansicht, um die Benutzeroberfläche bereitzustellen, die Entwickler finden, wenn sie auf die Entwicklertools zugreifen. Es enthält:
- Symbolleiste zum Aktivieren der virtuellen Authenticator-Umgebung.
- Ein Abschnitt zum Hinzufügen von Authenticators.
- Ein Abschnitt für erstellte Authenticators.
(Code lesen)
Symbolleiste zum Aktivieren der virtuellen Authenticator-Umgebung
Da die meisten Nutzerinteraktionen mit jeweils einem Authenticator statt mit dem gesamten Tab stattfinden, ist die einzige Funktionalität, die wir in der Symbolleiste anbieten, das Ein- und Ausschalten der virtuellen Umgebung.
Warum ist das notwendig? Es ist wichtig, dass der Nutzer die Umgebung explizit umschalten muss, da dadurch der Browser von der tatsächlichen Authenticator Discovery getrennt wird. Solange diese Funktion aktiviert ist, werden verbundene physische Authenticatoren wie ein Fingerabdruckleser nicht erkannt.
Wir haben entschieden, dass eine explizite Ein-/Aus-Schaltfläche die Nutzererfahrung verbessert, insbesondere für diejenigen, die den Tab „WebAuthn“ aufrufen, ohne zu erwarten, dass die Erkennung deaktiviert wird.
Abschnitt „Authenticators“ hinzufügen
Nach dem Aktivieren der virtuellen Authenticator-Umgebung stellen wir dem Entwickler ein Inline-Formular zur Verfügung, mit dem er einen virtuellen Authenticator hinzufügen kann. In diesem Formular bieten wir Anpassungsoptionen, mit denen der Nutzer über das Protokoll und die Transportmethoden des Authenticator entscheiden kann, ob er residente 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 Authenticator vornimmt. Sobald dies abgeschlossen ist, erhält das Front-End eine Antwort und ändert dann die Benutzeroberfläche so, dass sie den neu erstellten Authenticator enthält.
Authenticator-Ansicht
Jedes Mal, wenn ein Authenticator emuliert wird, wird der Authenticator-Ansicht ein Abschnitt hinzugefügt, um ihn darzustellen. Jeder Authenticator-Abschnitt enthält einen Namen, eine ID, Konfigurationsoptionen, Schaltflächen zum Entfernen oder Aktivieren des Authenticator sowie eine Tabelle mit Anmeldedaten.
Der Authenticator-Name
Der Name des Authenticator ist anpassbar und wird standardmäßig auf „Authenticator“ (Authenticator) gesetzt, verkettet mit den letzten fünf Zeichen seiner ID. Ursprünglich war der Name des Authenticator die vollständige ID und kann nicht geändert werden. Wir haben benutzerdefinierte Namen implementiert, damit der Nutzer den Authenticator basierend auf seinen Funktionen, dem physischen Authenticator, der emuliert werden soll, oder einem beliebigen Alias, der etwas einfacher zu verarbeiten ist, als eine ID mit 36 Zeichen beschriften kann.
Tabelle mit Anmeldedaten
Wir haben jedem Authenticator-Abschnitt eine Tabelle hinzugefügt, in der alle von einem Authenticator registrierten Anmeldedaten angezeigt werden. In jeder Zeile sind Informationen zum Berechtigungsnachweis sowie Schaltflächen zum Entfernen oder Exportieren des Berechtigungsnachweises enthalten.
Derzeit erfassen wir die Informationen zum Ausfüllen dieser Tabellen, indem wir das CDP abfragen, um die registrierten Anmeldedaten für jeden Authenticator zu erhalten. Für die Zukunft planen wir, ein Ereignis für die Erstellung von Anmeldedaten hinzuzufügen.
Schaltfläche „Aktiv“
Außerdem wurde jedem Authenticator-Abschnitt das Optionsfeld Aktiv hinzugefügt. Nur der Authenticator, der derzeit aktiv ist, wartet auf Anmeldedaten und registriert ihn. Andernfalls ist die Registrierung von Anmeldedaten bei mehreren Authenticatoren nicht deterministisch, was ein schwerwiegender Fehler wäre, wenn WebAuthn mit ihnen getestet würde.
Wir haben den Status „Aktiv“ mithilfe der Methode SetUserPresence auf virtuelle Authenticators implementiert. Die Methode SetUserPresence legt fest, ob Tests der Nutzerpräsenz für einen bestimmten Authenticator erfolgreich sind. Wenn wir sie deaktivieren, kann ein Authenticator nicht auf Anmeldedaten warten. Wir können deterministisches Verhalten erzwingen, indem wir sicherstellen, dass die Funktion nur für maximal einen Authenticator aktiviert ist (denjenigen, der als aktiv festgelegt ist) und die Nutzerpräsenz für alle anderen deaktiviert.
Eine interessante Herausforderung beim Hinzufügen der aktiven Schaltfläche war das Vermeiden einer Race-Bedingung. Stellen Sie sich folgendes Szenario vor:
Der Nutzer klickt auf das Optionsfeld Aktiv für Authenticator X und sendet eine Anfrage an den CDP, um X als aktiv festzulegen. Das Optionsfeld Aktiv für X ist ausgewählt und alle anderen sind nicht ausgewählt.
Unmittelbar danach klickt der Nutzer auf das Optionsfeld Aktiv für Authenticator Y und sendet eine Anfrage an das CDP, um Y als aktiv festzulegen. Das Optionsfeld Aktiv für Y ist ausgewählt und alle anderen Schaltflächen, auch für X, sind nicht ausgewählt.
Im Back-End wird der Aufruf zum Festlegen von Y als aktiv abgeschlossen und aufgelöst. Y ist jetzt aktiv, alle anderen Authenticatoren nicht mehr.
Im Back-End wird der Aufruf zum Festlegen von X als aktiv abgeschlossen und aufgelöst. X ist jetzt aktiv und alle anderen Authenticatoren, einschließlich Y, nicht mehr.
Nun ergibt sich folgende Situation: 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 Y ist jedoch ausgewählt. Es gibt einen Widerspruch zwischen dem Front-End und dem tatsächlichen Status der Authenticatoren. Offensichtlich ist das ein Problem.
Unsere Lösung: Richten Sie eine bidirektionale Kommunikation zwischen den Optionsfeldern und dem aktiven Authenticator ein. Zunächst verwalten wir eine Variable activeId in der Ansicht, um die ID des derzeit aktiven Authenticator zu verfolgen. Anschließend warten wir, bis der Aufruf einen aktiven Authenticator aktiviert, und legen activeId auf die ID dieses Authenticator fest. Zum Schluss gehen wir jeden Authenticator-Abschnitt durch. Wenn die ID dieses Abschnitts gleich activeId ist, wird die Schaltfläche auf „ausgewählt“ gesetzt. Andernfalls wird die Schaltfläche auf nicht ausgewählt gesetzt.
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 verfolgen. Zu Beginn haben wir uns zwei Optionen ausgedacht.
Jedes Öffnen des Tabs „WebAuthn“ in den Entwicklertools zählen. Diese Option kann zu einer Überzählung führen, da der Tab möglicherweise geöffnet wird, ohne ihn zu verwenden.
Verfolgen Sie, wie oft das Kästchen „Virtuelle Authenticator-Umgebung aktivieren“ in der Symbolleiste aktiviert wurde. Diese Option könnte auch zu einem Problem mit zu vielen Zählungen führen, da einige Nutzer die Umgebung mehrmals in derselben Sitzung ein- und ausschalten können.
Wir haben uns für Letzteres entschieden, aber die Zählung eingeschränkt, indem wir überprüft haben, ob die Umgebung bereits für die Sitzung aktiviert wurde. Daher würden wir die Anzahl nur um 1 erhöhen, unabhängig davon, wie oft der Entwickler die Umgebung umgeschaltet hat. Dies funktioniert, weil bei jedem Öffnen des Tabs 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 Vorschläge zur Verbesserung des Tabs „WebAuthn“ haben, melden Sie uns einen Programmfehler.
Hier finden Sie einige Ressourcen, wenn Sie mehr über WebAuthn erfahren möchten:
- WebAuthn-Entwicklertools – Front-End-Designdokument
- Designdokument für Web Authentication Testing API
- WebAuthn-Spezifikation (Web Authentication API)
- Erläuterung und Anleitung zu WebAuthn
Vorschaukanäle herunterladen
Du kannst Chrome Canary, Dev oder Beta als Standardbrowser für die Entwicklung verwenden. Mit diesen Vorschaukanälen erhalten Sie Zugriff auf die neuesten Funktionen der Entwicklertools, können bahnbrechende Webplattform-APIs testen und Probleme auf Ihrer Website erkennen, noch bevor Ihre Nutzer dies tun.
Chrome-Entwicklertools-Team kontaktieren
Verwende die folgenden Optionen, um die neuen Funktionen und Änderungen im Beitrag oder andere Themen im Zusammenhang mit den Entwicklertools zu besprechen.
- Sende uns über crbug.com einen Vorschlag oder Feedback.
- Wenn du ein Problem mit den Entwicklertools melden möchtest, klicke in den Entwicklertools auf Weitere Optionen
> Hilfe > Probleme mit Entwicklertools melden. - Senden Sie einen Tweet an @ChromeDevTools.
- Hinterlasse Kommentare unter YouTube-Videos oder YouTube-Videos mit Tipps zu DevTools.