Die Abkehr vom Passwort zur Verbesserung der Account-Sicherheit ist immer wieder ein Thema für Administratoren und Sicherheitsforscher. Seit gut und gerne zwei Jahrzehnten werden Business-Notebooks serienmäßig mit Fingerabdruck-Sensor verkauft. Das mit Windows 2000 eingeführte "Graphical Identification and Authentication" (GINA) ermöglichte bereits die Verwendung des Fingerabdrucks zum Windows-Login. Zwar wurde GINA bereits mit Windows Vista wieder abgeschafft, die Funktionalität aber blieb erhalten. Und während Forscher die Technik immer wieder überlisten konnten, entwuchs diese den Kinderschuhen und dient seit einiger Zeit auch Logins auf Smartphones.

Was lokal heute gut funktioniert, ist so bisher nicht für entfernte Anmeldungen nutzbar. Im Internet dominiert noch immer das Passwort als wissensbasierter Faktor der Authentifikation die Loginmethoden von Onlinediensten. Passwortmanager entlasten dabei zwar die Benutzer als Schwachstelle bei der Passwortwahl zunehmend. Doch aller technischen Unterstützung zum Trotz verwenden aber auch heute noch viele Benutzer einfach zu merkende und somit auch einfach zu knackende Passwörter.

Während Projekte wie "Have I Been Pwned" [1] oder die Forscher der Universität Bonn in ihrem EIDI-Projekt [2] einen reaktiven Ansatz zur Kontensicherheit verfolgen, sollte der Fokus in der Webentwicklung mehr auf alternative Authentifikationsmethoden liegen. Bereits im Dezember 2014 hat die FIDO Alliance den Standard "FIDO Universal Authentication Framework" (FIDO UAF) veröffentlicht, der passwortlose Authentifikation ermöglichen sollte. Schon vor dem Release von Windows 10 kündigte Microsoft Anfang 2015 die Unterstützung von FIDO im neuen Betriebssystem an. Bewegung in die Sache kam jedoch erst 2018. Seit der Veröffentlichung des FIDO2-Standards mit den Bestandteilen "Web Authentication" (WebAuthn) und "Client to Authenticator Protocol" (CTAP) unterstützen nach und nach alle gängigen Browser die Web-Authentication-Java-Script-API und die Verwendung von Sicherheitstoken mittels CTAP.

Funktionsweise von FIDO2

FIDO2 ist glücklicherweise sehr überschaubar und, obwohl es maßgeblich auf kryptografischen Schlüsseln basiert, recht einfach zu verstehen. Bevor Sie sich als Benutzer bei einem Webdienst einloggen können, müssen Sie zunächst einen Registrierungsprozess durchlaufen. Dabei erzeugen Sie auf einem sicheren Gerät, dem sogenannten Authenticator, das kryptografische Schlüsselmaterial – einen öffentlichen und einen privaten Schlüssel. Sie übermitteln den öffentlichen Schlüssel zur späteren Authentifikation an den Anwendungsserver. Dieser wird dort hinterlegt und mit Ihrem Benutzerkonto verknüpft. Der private Schlüssel bleibt sicher abgelegt auf dem Authenticator. Beim Authenticator kann es sich um ein externes Gerät oder etwa den TPM-Chip in Ihrem Computer handeln.

Schematisch läuft der Login an einem Webdienst (Relying Party) wie folgt ab: Die Webanwendung (Relying Party Application) wird in Ihrem Webbrowser ausgeführt. Der Server übermittelt eine Challenge an Ihren Browser, die dieser mit dem privaten Schlüssel signiert und wieder an den Webdienst sendet. Mittels der Java-Script-API werden aus der Anwendung heraus die Funktionen des Browsers für die FIDO-Authentifikation angesprochen.

Je nachdem, welches Gerät Sie bei der Registrierung für die Schlüsselerzeugung verwendet haben, greift Ihr Browser über das Betriebssystem auf den TPM-Chip Ihres Computers oder mittels CTAP-Protokoll auf einen externen Authenticator zu.

Dieser besitzt den privaten Schlüssel und muss die Signatur für die Challenge erzeugen. Der Vorgang ist häufig noch einmal mit der Eingabe einer PIN oder dem Präsentieren eines biometrischen Merkmals, etwa dem Fingerabdruck, verbunden. An lokalen Geräten funktioniert die passwortlose Authentifikation mittels Biometrie wie erwähnt bereits problemlos. Die signierte Challenge gibt der Authenticator zurück an den Browser, der sie an den Anwendungsserver weiterreicht. Dieser überprüft die Signatur mit dem hinterlegten öffentlichen Schlüssel. Ist diese korrekt, ist der Login erfolgreich abgeschlossen.

Im Vergleich zur Authentifizierung mittels Clientzertifikat im Browser gibt es bei diesem Ansatz einen entscheidenden Unterschied: Sie benötigen keine Zertifizierungsstelle, die für Sie die Identität des Benutzers überprüft und anschließend ein Zertifikat ausstellt. Die tatsächliche Identität des Benutzers steht bei FIDO, wie ja auch bei der Passwort-basierten Authentifikation, gar nicht im Vordergrund. Vielmehr geht es darum, einen Benutzer zuverlässig wiederzuerkennen. Sie können also mit FIDO auch eine sichere Authentifikation von grundsätzlich anonymen Benutzerkonten durchführen. Auch die Verwendung mehrerer, auch unterschiedlicher Schlüssel ist so sehr einfach möglich. FIDO2 erlaubt Ihnen als Anbieter sogar, die Art der als Authenticator eingesetzten Geräte vorzuschreiben und zu überprüfen. Im Rahmen einer Zertifizierung wird ein Modell-Schlüsselpaar erzeugt, das sich ebenfalls in den Signaturprozess einbinden lässt. So stellen Sie als Anbieter sicher, dass Ihre Kunden bestimmte Geräteklassen verwenden, etwa solche, die nur mit einer PIN oder einem Fingerabdruck freizuschalten sind. Dieses Modell-Schlüsselpaar wird dann auf allen Geräten eines bestimmten Modells installiert, ist also Geräte-spezifisch, aber nicht Geräte-individuell.

Vertrauenswürdiger Authenticator

Zur Signatur der Challenge vom Anwendungsserver benötigen Sie ein weiteres Gerät, den sogenannten Authenticator. Dabei kann es sich um ein internes Gerät, etwas das Trusted-Platform-Module (TPM) in Ihrem Rechner, oder um ein externes Gerät, etwa einen USB-Sicherheitstoken wie den Yubikey, handeln. Seit Februar 2019 ist auch Android FIDO2-zertifiziert. Damit haben Sie auf Geräten mit passender Hardware und Android 7 oder höher den internen Authenticator immer dabei. Diesen können Sie über ihren Fingerabdruck oder die PIN der Bildschirmsperre freischalten. Für die Kommunikation mit dem Sicherheitstoken definiert FIDO die Client-to-Authenticator-Protokolle CTAP1 und CTAP2. Version 1 wird auch Universal-2nd-Factor (U2F) und Version 2 FIDO2- oder WebAuthn-Protokoll genannt. Zum Testen verwenden wir in diesem Artikel einen Yubikey-NFC-Stick in Version 5 und ein aktuelles Android-Smartphone. Der Yubikey wird unter Linux direkt als "Yubico YubiKey OTP+FIDO+CCID" erkannt. Überprüfen Sie das beim Einstecken, indem Sie mit folgendem Kommando die Ausgaben des Kernels beobachten:

sudo dmesg -w

Anschließend können Sie für erste Tests auf die WebAuthn-Demoseite [3] gehen. Wenn der Authenticator mit Ihrem Browser funktioniert, ist der nächste Schritt, FIDO2 auf einer eigenen Webseite auszuprobieren.

Serveranwendung erstellen

Um die folgenden Beispiele testen zu können, verwenden wir die PHP-WebAuthn-Bibliothek von Lukas Buchs [4]. Nutzen Sie bereits einen PHP-fähigen Server, können Sie die Beispielanwendung im "_test"-Ordner direkt verfügbar machen und die Seite ausliefern. Ohne entsprechende Umgebung setzen Sie mit Docker-Compose einfach und schnell nginx mit PHP auf. Verwenden Sie dafür die Datei "docker-compose.yaml" aus Listing 1.

Die Konfiguration von nginx übernimmt die Datei "default.conf" aus Listing 2. Diese konfiguriert die Weiterleitung zum PHP-FPM-Server für alle Dateien, die auf ".php" enden. Da die Datei "client.html", die als statische Seite ausgeliefert wird, im selben Ordner liegt wie die Datei "server.php", wird in "docker-compose.yaml" derselbe Ordner in beide Container eingebunden.

Sie starten die beiden Docker-Container nun mit

docker-compose up

Rufen Sie danach die URL "http://localhost:8080/WebAuthn/_test/client.html" in Ihrem Browser auf, werden Sie auf eine sichere HTTPS-Seite umgeleitet, wobei diese Verbindung dann fehlschlägt. Die Umleitung ist in der Datei "client.html" definiert. Für unsere lokalen Tests ist das aber nicht nötig. Daher entfernen Sie in "client.html" die JavaScript-Anweisungen in den Zeilen 226 bis 230, die mit "win­dows.onload" beginnen. Anschließend müssen Sie vermutlich den Browser-Cache leeren, damit die Umleitung nicht immer wieder direkt ausgeführt wird.

Sie erreichen jetzt unter der genannten URL die Webseite der Testanwendung. Dort können Sie mit einem Klick auf "New Registration" die WebAuthn-API Ihres Browsers ansprechen und das vorhandene Sicherheitstoken registrieren. Wenn Sie die Benutzung später etwa auch von Ihrem Smartphone aus testen möchten, müssen Sie ein gültiges SSL-Zertifikat installieren. Unter Android erhalten Sie sonst unter Umständen einen Hinweis, dass der Browser nicht kompatibel sei.

Passwortlose Authentifikation mit PHP

Um Ihnen die Möglichkeit zu geben, eine eigene Webanwendung mit FIDO2 auszustatten, orientieren wir uns an der Beispielanwendung und suchen für einen abstrakten eigenen Dienst die relevanten Bestandteile in den Beispielen.

Als konkreten Anwendungsfall betrachten wir also die passwortlose Authentifikation mit PHP auf Basis der genannten Web­Authn-Bibliothek. Wir gehen dabei davon aus, dass sich Ihr Webdienst auf PHP-Basis auf einem öffentlich erreichbaren Server befindet und Sie bereits ein gültiges Zertifikat zum Beispiel von Let's Encrypt für den Server installiert haben. Als Datenbank verwenden Sie ein Datenbank-Management-System Ihrer Wahl, wo Sie auch mehrere öffentliche Schlüssel für jeden Ihrer Benutzer speichern können.

Bedienen Sie sich für das JavaScript Ihrer Webanwendung bei der Datei "client. html" im Verzeichnis "_test" der Web­Authn-Bibliothek und speichern Sie die Funktionen in einer eigenen Datei ab, beispielsweise "fido.js", die Sie auf der Login-Seite Ihres Webdienstes einbinden. Auf die Funktion "clearregistration()" können Sie dann verzichten, wenn Sie eine andere Möglichkeit für die Verwaltung der hinterlegten öffentlichen Schlüssel planen.

Haben Sie bereits eine funktionierende Anwendung mit Login, sollten Sie die Pfade in den vier verbleibenden Aufrufen der Funktion "window.fetch" anpassen. Die Parameter für die HTTP-Abfragen, die aus der Methode "getGetParams()" kommen, benötigen Sie eigentlich nicht. Die CA-Zertifikate sind optional und wir planen zunächst keine Einschränkung, was den Hersteller von Sicherheitstoken angeht.

Anfragen mit GET und POST

Sie können mit PHP sehr einfach zwischen den Methoden GET und POST unterscheiden. Daher benötigen Sie nur zwei unterschiedliche Pfade, die Sie entsprechend der Anfragemethode zu zwei Funktionen Ihrer Webanwendung routen können. Nehmen wir dafür die beiden Pfade "/fido/create" und "/fido/login". Unter "/fido/create" fragen Sie mit GET die Parameter zur Erstellung eines neuen Schlüsselpaares ab und laden mit POST die Signatur hoch, um so den öffentlichen Schlüssel auf dem Server zu hinterlegen. Unter "/fido/login" nutzen Sie die GET-Methode wieder zur Anfrage der Parameter für die Signatur und mit POST versenden sie diese Signatur an den Server zur Authentifikation.

Wichtig ist, dass Sie immer den Benutzernamen mitsenden müssen. Nur wenn dieser bekannt ist, lässt sich der hinterlegte öffentliche Schlüssel dem richtigen Konto zuordnen und einloggen. Den Benutzernamen können Sie beispielsweise mit in den Pfad integrieren. Der Pfad "/fido/create/user/Hans" kommt dann zum Einsatz, um den öffentlichen Schlüssel für den Benutzer "Hans" zu erstellen und hochzuladen. Dabei lesen Sie mit folgendem Kommando den Benutzernamen einfach dynamisch aus einem entsprechenden Eingabefeld ihres Loginformulars aus und fügen die Werte noch den zuvor definierten Pfaden hinzu:

user_url = 'user/' + (document.getElementById('user').value) + '/';

Je nachdem, ob Sie den Benutzer zum Zeitpunkt der Neuregistrierung eines öffentlichen Schlüssels bereits authentifiziert haben und etwa über eine gültige Sitzung wiedererkennen, brauchen Sie die Angabe des Benutzers in der URL dann nur für den Login, also die Funktionen unter "checkregistration()". Wenn die Pfade angepasst sind und der Benutzername zuverlässig mit übergeben wird, ist die Clientseite bereits fertig eingerichtet.

Bevor wir die Anpassungen auf unserer Serverseite vornehmen, werfen wir nochmal einen Blick in die Datei "server.php" der Beispielanwendung unter "_test". Hier gibt es vier Funktionsbereiche, wobei Sie jeweils einen für einen der oben genannten Pfade verwenden können. Die künstlerische ASCII-Darstellung des Ablaufs im Kopfbereich der Datei verdeutlicht Ihnen noch einmal den Ablauf der Registrierung und Überprüfung. Gemeinsam übernehmen wir die vier relevanten Bereiche für die unterschiedlichen Endpunkte unseres abstrakten Projekts.

In der Datei erfolgt im oberen Bereich die Auswahl der unterstützten Formate anhand der übergebenen HTTP-Argumente. Da wir uns bei der Wahl des Sicherheitstoken erst einmal nicht einschränken wollen, müssen wir in einem Array alle unterstützten Geräte übergeben:

$WebAuthn = new \WebAuthn\WebAuthn('IT-Administrator', 'it-administrator.de', array('fido-u2f', 'packed', 'android-key', 'android-safetynet', 'none'));

Wir erstellen also zuerst immer ein WebAuthn-Objekt, das uns die weitere Arbeit größtenteils abnehmen kann. Wir übergeben diesem zur Referenzierung einen beliebigen Namen unserer Anwendung und als ID der Relying-Party den Namen der Domain. Dieser wird dem Benutzer beim Erstellen und bei der Eingabe zur Überprüfung angezeigt.

Schlüsselpaar erstellen mit Create

Zum Erstellen eines neuen Schlüsselpaares haben wir einen Endpunkt unter "/fido/create" angelegt. Im Ablauf unterscheiden wir im Aufruf zwischen der GET- und der POST-Methode. Zunächst nutzt der JavaScript-Client die GET-Methode. Der Server sendet mit den folgenden Kommandos die notwendigen Informationen an den Client:

$WebAuthn = new \WebAuthn\WebAuthn('IT-Administrator', 'it-administrator.de', array('fido-u2f', 'packed', 'android-key', 'android-safetynet', 'none'));

$createArgs = $WebAuthn->getCreateArgs($benutzer_id, $nick, $anzeigename);

Dabei können die Werte der drei Argumente für "getCreateArgs()" auch identisch sein. Sie sollten nur für jeden Benutzer einzigartig sein, denn sie dienen der Unterscheidung verschiedener Schlüssel auf dem Sicherheitstoken, falls dieser das unterstützt. Um den neuen Schlüssel zu akzeptieren, wird eine Challenge mitgesendet, die auf dem Token signiert und im zweiten Schritt mit dem öffentlichen Schlüssel hochgeladen wird. Diese speichern wir bestenfalls in der aktuellen Benutzersession und geben anschließend die erstellen Parameter im JSON-Format an den JavaScript-Client zurück. Damit ist der erste Schritt abgeschlossen:

$_SESSION['fido_challenge'] = $WebAuthn->getChallenge();

print(json_encode($createArgs));

return;

Nun wartet der Server auf den Versand des öffentlichen Schlüssels und der ersten Signatur, die sich damit überprüfen lässt. Auf einem Android-Smartphone können Sie nun, wie in Bild 1 dargestellt, auswählen, welche Authentifikations-Methode Sie lokal am Smartphone zur Freischaltung des privaten Schlüssels verwenden möchten.

Auch wenn das in der Beispielanwendung nicht vorgesehen ist, empfehlen wir in Ihrer Anwendung die zusätzliche Angabe eines Namens für den Token beziehungsweise das Gerät durch den Anwender, sodass später eine einfache Zuordnung möglich ist. Diesen Namen übertragen wir nun ebenfalls in der POST-Anfrage an "/fido/create". In der aufgerufenen Methode muss nun die erzeugte Signatur mit dem ebenfalls hochgeladenen öffentlichen Schlüssel überprüft werden. Dafür lesen wir diese wie folgt aus dem Body der Anfrage und werten das enthaltene JSON entsprechend aus:

$post = trim(file_get_contents('php://input'));

if ($post) {

$post = json_decode($post);

}

Der Token sendet auch eine eindeutige Credential-ID, die für ihn zur Identifikation des Schlüsselpaares verwendet wird. Diese Credential-ID und der öffentliche Schlüssel werden für den angemeldeten Benutzer in der Datenbank gespeichert. Die anderen Werte müssen nicht dauerhaft hinterlegt sein. Für das Erstellen des Objekts erfolgt zuerst das Auslesen der Challenge aus der Session:

$challenge = $_SESSION['fido_challenge'];

Hier kann es passieren, dass Sie vor dem Auslesen der Challenge aus der Session-Variable einen Fehler erhalten. Tatsächlich taucht dieser Fehler schon beim Start der Session auf, wenn PHP versucht, das Objekt vom Typ "\WebAuthn\Binary\Byte­Buffer" zu erzeugen, bevor die Klasse dem Skript bekannt ist. Hier schaffen Sie Abhilfe, indem Sie einfach vor "session_start()" die WebAuthn-Bibliothek einbinden und mit "use" die Klasse bereits vorab laden:

require_once 'WebAuthn/WebAuthn.php';

use WebAuthn\Binary\ByteBuffer;

Dann müssen die im Base64-Format vorliegenden Benutzerinformationen und die Informationen über den Authenticator dekodiert werden. Dies startet einen Erzeugungsprozess, der im Erfolgsfall bei gültiger Signatur der Challenge ein entsprechendes Objekt zurückgibt. Im Code sieht das folgendermaßen aus:

$clientDataJSON = base64_decode($post->client­DataJSON);

$attestationObject = base64_decode($post->attestation-Object);

$data = $WebAuthn->processCreate($clientDataJSON, $attestationObject, $challenge);

Aus dem Objekt in der Variablen "$data" lassen sich nun die notwendige Credential-ID und der öffentliche Schlüssel des Benutzers auslesen. Wie Sie diese Werte in Ihrer Datenbank speichern, hängt dabei von Ihrer vorliegenden Konfiguration ab. Allerdings sollten Sie die Credential-ID vor dem Abspeichern wieder Base64-kodieren, da viele Datenbanken die Binärdaten nicht problemfrei übernehmen. Der öffentliche Schlüssel liegt im PEM-Format vor und ist damit bereits Base64-kodiert:

$credentialId = base64_encode($data->credentialId);

$credentialPublicKey = $data->credentialPublicKey;

Bedenken Sie, dass es für jeden Benutzer möglich sein sollte, mehrere öffentliche Schlüssel zu hinterlegen. So behält der Benutzer den Zugriff zu seinem Konto auch dann, wenn er einen der Token nicht mehr nutzen kann. Haben Sie diese Werte passend für Ihre Datenbank abgespeichert, können Sie Erfolg vermelden. Der Java-Script-Client nimmt dabei ein Objekt in JSON an und wertet die Felder "success" und "msg" aus:

$return = new stdClass();

$return->success = true;

$return->msg = 'Registration Success.';

print(json_encode($return));

return;

Damit ist das Erzeugen des Schlüssels erfolgreich abgeschlossen und Sie können sich in der Datenbank vergewissern, dass die beiden Werte dort gespeichert sind.

Erster Login

Der öffentliche Schlüssel und die vom Sicherheitstoken vergebene Credential-ID sind in der Datenbank gespeichert, nun möchte sich der Benutzer an Ihrem System anmelden. Auch hier gilt wieder, dass er zunächst per GET die Challenge und weitere Parameter vom Anwendungsserver abfragt. Da Sie zu diesem Zeitpunkt keine gültige Session haben, muss der JavaScript-Client Ihrer Anwendung den Benutzernamen abfragen oder, wie beschrieben, aus einem Loginformular auslesen. Mit dem Benutzernamen, den Sie der Einfachheit halber über die URL übergeben, lassen sich nun alle hinterlegten Credential-IDs des Benutzers aus der Datenbank auslesen. Bedenken Sie, dass diese Base64-kodiert abgespeichert sind. Wir übermitteln dem Client alle gespeicherten IDs, so kann er eine passende auswählen. Den öffentlichen Schlüssel brauchen Sie in diesem Aufruf noch nicht. Erstellen Sie also die Challenge mit den folgenden Kommandos, dabei müssen Sie die Variablen und Indexe im "foreach"-Konstrukt an Ihre Datenbank-Struktur anpassen:

$ids = array();

foreach($dbdata AS $credentials){$ids[] = base64_decode($credentials['credentialId']);

}

$getArgs = $WebAuthn>getGetArgs($ids);

$_SESSION['challenge'] = $WebAuthn->getChallenge();

print(json_encode($getArgs));

return;

Nun kann der Client mit einem für die IDs passenden Sicherheitstoken die Challenge signieren und die Signatur per POST im Body der Anfrage an die Webanwendung zurücksenden. Die Aufforderung zur Auswahl eines Sicherheitstokens in Firefox sehen Sie in Bild 2.

Lesen Sie nun wieder den HTTP-Body der Anfrage aus und dekodieren das enthaltene JSON, wie zuvor gezeigt. Mit den folgenden Kommandos nehmen wir die Daten auseinander und dekodieren wieder die enthaltenen Base64-Daten:

$clientDataJSON = base64_decode($post->client­DataJSON);

$authenticatorData = base64_decode($post->authenticatorData);

$signature = base64_decode($post->signature);

$credentialId = base64_decode($post->id);

Nun suchen Sie den zur Credential-ID passenden öffentlichen Schlüssel in Ihrer Datenbank und speichern ihn in der Variablen "$credentialPublicKey". Denken Sie auch hierbei wieder daran, dass die Daten in der Datenbank Base64-kodiert sind. Sollte es keinen passenden Schlüssel geben, senden Sie einen entsprechenden Fehler zurück. Nutzen Sie dafür wie oben gezeigt ein Objekt und die Attribute "success" und "msg". Wurde der öffentliche Schlüssel gefunden, benötigen Sie noch die Challenge aus der Session und können damit anschließend die Überprüfung durchführen:

$challenge = $_SESSION['challenge'];

$WebAuthn->processGet($clientDataJSON, $authenticatorData, $signature, $credentialPublicKey, $challenge);

Dieses Kommando verursacht bei einem Fehler während der Überprüfung eine WebAuthnException, die Sie entsprechend behandeln sollten. Ohne Fehler gilt der Benutzer als eingeloggt. Erstellen Sie, wie nach einem normalen Login auch, alle Sitzungsdaten. Anschließend melden Sie den Erfolg wie oben an den Client zurück. Dort können Sie bei Bedarf die Seite einfach mittels JavaScript neu laden oder eine Umleitung auf eine Unterseite konfigurieren.

Weitere Nutzungsmöglichkeiten

Wenn Sie wie dargestellt einmal durch die Entwicklung eines FIDO2-Logins gegangen sind, fallen Ihnen sicher viele mög­liche Anpassungen für den Prozess ein. So lässt sich mit ent­sprechenden Informationen auch eine Authentifikation ganz ohne Angabe von Benutzernamen implementieren. Oder Sie nutzen FIDO2 als zweiten Faktor, so wie bereits einige Onlinedienste von der Funktionalität Gebrauch machen. Mit Windows 10 und Microsoft Hello als Authenticator nutzen Sie FIDO2 auch auf den Geräten in Ihrer Windows-Domäne.

Fazit

In diesem Artikel haben Sie für einen Webdienst den Login mittels FIDO2 ermöglicht. Wenn Sie statt PHP lieber andere Sprachen für Ihre Webentwicklung verwenden, finden Sie dafür ähnliche Bibliotheken. Das Prinzip bleibt dabei erhalten und auch die JavaScript-Seite des Clients müssen Sie nicht unbedingt anpassen. Probieren Sie einfach die unterschiedlichen Konfigurations- und Nutzungsmöglichkeiten von FIDO2 aus.

(dr)