Migration zu Passkeys: Passwortlose Webanwendungen

Passwörter sind seit dem Beginn des Computerzeitalters der Status Quo zur Authentifizierung. Veränderte technische Rahmenbedingungen und die stark gestiegene Verbreitung von digitalen Systemen macht die Relevanz einer sicheren Authentifizierung deutlich. Um die zahlreichen Schwächen von Passwörtern zur Authentifizierung in Webanwendungen zu beheben, existiert seit 2016 mit WebAuthn ein Standard für passwortlose Authentifizierung. Mit der Erweiterung auf Passkeys einige Jahre später erfährt die Technologie zunehmende Verbreitung. Während die technische Umsetzung in Browsern und Plattformen bereits etabliert ist, ist die Integration von Passkeys in eine konkrete Webanwendung und insbesondere die Migration zu Passkeys für viele Projekte noch unklar. Zur Implementierung existieren mehrere Varianten, die in diesem Artikel evaluiert werden.

Die Unsicherheit von Passwörtern

Die Sicherheitsprobleme mit herkömmlichen Passwörtern werden durch zahlreiche alarmierende Statistiken unterstrichen. Schwache oder gestohlene Passwörter sind verantwortlich für 81 % der durch Hacking verursachten Datenlecks. Ein wesentlicher Faktor dabei sind Credential-Phishing-Angriffe, bei denen Nutzer:innen auf täuschend echte Webseiten gelockt werden, die vertraute Benutzeroberflächen nachahmen und zur Eingabe von Anmeldeinformationen auffordern. Im Jahr 2022 gaben 89 % befragter Unternehmen an, von Phishing-Angriffen betroffen gewesen zu sein. Die rasante Entwicklung generativer KI verschärft die Lage zusätzlich, da Cyberkriminelle nun Phishing-Angriffe noch schneller und raffinierter durchführen können. Dies führte in den letzten sechs Monaten zu einem besorgniserregenden Anstieg der Phishing-Angriffe um 217 %. Obwohl Zwei-Faktor-Authentifizierung (2FA) und Passwortmanager einen gewissen Schutz bieten, bekämpfen sie lediglich die Symptome und nicht die eigentliche Ursache des Problems. Dieser Verlauf verdeutlicht, dass Passwörter nicht mehr ausreichen, um die Sicherheit von Daten und Identitäten zu gewährleisten.

Die gute Nachricht ist, dass es bereits eine geeignete Alternative gibt: Passkeys! Diese innovative Authentifizierungsmethode wurde Mitte 2022 von führenden Technologieunternehmen wie Apple, Google und Microsoft eingeführt. Eine wachsende Anzahl namhafter Unternehmen wie Adobe, Nvidia, Amazon oder PayPal unterstützt bereits Passkeys. Passkeys können nicht nur herkömmliche Passwörter ersetzen, sondern auch dazu beitragen, sämtliche Sicherheitsrisiken zu minimieren – wie beispielsweise Phishing-Angriffe – und gleichzeitig die Nutzungsfreundlichkeit verbessern.

In diesem Blogbeitrag werden die verschiedenen Implementierungsansätze zur Integration von Passkeys in Webanwendungen erläutert und gegenübergestellt. Zusätzlich bietet der Artikel eine Handlungsempfehlung zur Auswahl eines Ansatzes für die vorliegende Ausgangssituation. Abschließend werden Aspekte aufgeführt, die es bei einer Migration zu Passkeys zu beachten gilt.

Migration zu Passkeys in Webanwendungen

Die unterschiedlichen Möglichkeiten zur Migration einer Anwendung zu Passkeys werden im Folgenden am Beispiel von scrumlr.io vorgestellt. Scrumlr ist eine Webanwendung für kollaborative Online-Retrospektiven, die von inovex entwickelt und betrieben wird und open-source gestellt wurde. Die Migration von Scrumlr brachte dabei Erkenntnisse über die Implementierungsvarianten, insbesondere bei der Nutzung von Passkey-as-a-Service-Anbietern.

Eine funktionsfähige Integration von Passkeys sollte mindestens die folgenden drei Anforderungen erfüllen:

• Der User kann sich einen Passkey registrieren.
• Der User kann seine erstellten Passkeys verwalten.
• Der User kann sich mittels eines Passkeys authentifizieren.

Dies bedarf der Implementierung der zwei Passkey-Zeremonien für die Registrierung und Authentifizierung eines Users. Diese Zeremonien basieren auf dem FIDO2-Standard und erfordern eine Interaktion zwischen dem User (Client), dem Webservice (Relying Party) und dem Authenticator (z. B. Endgerät oder Security-Key). Der Client initiiert beispielsweise die Authentifizierung bei der Relying Party, bestätigt seine Identität mithilfe des Authenticators und asymmetrischer Kryptographie sowie dem Challenge-Response-Verfahren gegenüber der Relying Party. Weitere Einzelheiten zur genauen Funktionsweise können beispielsweise dem Webauthn Developer Guide von Yubico entnommen werden oder auch diesem Artikel. Darüber hinaus müssen sämtliche Zugriffsfunktionalitäten (CRUD) für die Zeremonien und die Verwaltung von Passkeys sowie eine benutzerfreundliche Oberfläche für Passkeys bereitgestellt werden.

Migration zu Passkeys mittels Library

Der erste von drei Ansätzen, hier als LIB bezeichnet, umfasst die eigenständige Implementierung ausschließlich durch Libraries sowohl für die Server- als auch für die Client-Seite, ohne externe Services. Die Libraries auf der Client-Seite bieten hauptsächlich entwicklerfreundliche Funktionen, die als Wrapper für die beiden Browser-API-Funktionen navigator.credentials.create (zur Registrierung eines Passkeys) und navigator.credentials.get (zur Authentifizierung mittels Passkeys) fungieren. Libraries auf der Serverseite sind insbesondere für die Erstellung von Passkey-spezifischen Objekten zuständig, die Optionen für die Registrierung und Authentifizierung beinhalten. Diese Objekte erleichtern den Informationsaustausch zwischen den beteiligten Parteien. Außerdem werden Funktionen bereitgestellt, die die Verifikation von Signaturen unterstützen. Diese Libraries helfen jedoch nicht bei der Verwaltung von Passkeys (CRUD-Operationen) oder der Erstellung einer geeigneten Benutzungsoberfläche.

Scrumlr wurde auf der Serverseite mit Go und auf der Clientseite mit TypeScript entwickelt. Für die Implementierung wurden passende Libraries ausgewählt – darunter go-webauthn für den Server und simpleWebAuthn für den Client. Weitere Alternativen sind unter anderem hier zu finden. Die Abläufe und Funktionsbezeichnungen variieren kaum zwischen den verschiedenen Libraries, da sie alle auf demselben FIDO2-Standard basieren. Die Entscheidungsfindung bei der Auswahl erfolgt daher vorwiegend nach persönlicher Präferenz.

Die Implementierung der Passkey-Zeremonie zur Registrierung eines Passkeys könnte unter Verwendung der Libraries folgendermaßen aussehen:

Der Prozess beginnt damit, dass der Client die Registrierung eines Passkeys durch einen HTTP-POST-Request an den Endpunkt */passkeys/beginRegistration auf dem Server initiiert. Nach der Konfiguration und Instanziierung der Go-Library generiert der Server auf die Anfrage des Clients spezielle Optionen (options).

Diese Optionen bestimmen den genauen Ablauf der Registrierung durch den Authenticator. Der aufrufende Client erhält die Optionen in der Antwort des Servers. Der Client nutzt anschließend die Optionen über die Funktion startRegistration der Client-TypeScript-Library um die Registrierung auf dem Authenticator anzustoßen. Diese Funktion fungiert als Wrapper der Browser-API-Funktion navigator.credentials.create(). Dabei wird im Wesentlichen ein Schlüsselpaar (Public- und Private-Key) generiert, um die benötigten Passkey-Verfahren der asymmetrischen Kryptographie nutzen zu können.

Die authenticatorResponse enthält den generierten Public-Key sowie weitere erforderliche Informationen, die der Client dann an den Endpunkt */passkeys/finishRegistration  des Servers sendet. Um die Passkey-Registrierungszeremonie abzuschließen, verwendet der Server die Funktion FinishRegistration.

Diese Funktion überprüft die Inhalte der authenticatorResponse und verifiziert hauptsächlich angewandte Signaturen, um die Authentizität und Integrität sicherzustellen. An diesem Punkt endet die Unterstützung durch Client- und Server-Libraries.

Nach erfolgreicher Verifikation ist der nächste Schritt die Verwaltung des Public Keys (credential) selbst. Dazu müssen sämtliche Zugriffsfunktionalitäten (CRUD) für das Speichern, Aktualisieren und Löschen eines Passkeys entwickelt werden. Außerdem ist es erforderlich, eine geeignete Nutzungsoberfläche zu erstellen, um sowohl die Verwaltung der Passkeys als auch die beiden Passkey-Zeremonien für die Registrierung und Authentifizierung zu ermöglichen.

Bei der Gestaltung der Benutzungsoberfläche im Scrumlr wurde sich an vorhandenen Lösungen wie passkeys.io sowie an Passkey-spezifischen Richtlinien der FIDO-Alliance orientiert. Diese Richtlinien beinhalten beispielsweise die Verwendung des offiziellen Passkey-Logos. Die Verwaltung und Registrierung von Passkeys könnte dann wie folgt aussehen:

Die Benutzungsoberfläche für die Authentifizierung wurde entsprechend diesem Design gestaltet:

Passkeys as a Service

Als Alternative zu LIB kann einer der zwei identifizierten Services, Hanko oder Corbado, verwendet werden, die jeweils die Integration von Passkeys über unterschiedliche Implementierungsansätze erleichtern.

Hanko verfolgt einen API-basierten Ansatz und stellt eine spezifische REST-API bereit, über die sämtliche Funktionalitäten für die Umsetzung der beiden Passkey-Zeremonien zur Registrierung und Authentifizierung genutzt werden können. Dies bedeutet, dass anstelle der Verwendung von Funktionen einer Library HTTP-Anfragen an eine REST-API gesendet werden, um beispielsweise eine Registrierung zu initiieren oder die Registrierung abschließend zu verifizieren. Der wesentliche Unterschied dieses Ansatzes liegt jedoch in der Verwaltung der Passkeys.

Im Gegensatz zum vorherigen LIB-Ansatz werden die Passkeys nun bei einem Service gespeichert, wodurch dieser auch sämtliche Zugriffsfunktionalitäten (CRUD) über die API bereitstellen muss.

Ein Endpunkt und dessen Nutzung zur Initiierung einer Registrierung beim Hanko-Service würde in der Programmiersprache Go dann beispielsweise folgender Struktur entsprechen.

Corbado als dritter und letzter Implementierungsansatz (WCO-Ansatz) bzw. Service stellt hingegen vorgefertigte Web Components bereit, die clientseitig eingebunden und konfiguriert werden müssen. Diese Web Components enthalten im Vergleich zu den anderen beiden Ansätzen bereits eine Passkey-spezifische Benutzeroberfläche und die Funktionalität, um die zwei Passkey-Zeremonien zu verwenden. Der WCO-Ansatz übernimmt ebenso die Verwaltung der Passkeys und somit die Entwicklung sämtlicher Zugriffsfunktionalitäten (CRUD).

Beispielsweise die Web Component für die Registrierung beziehungsweise Assoziierung eines Passkeys besitzt folgenden Aufbau und rendert lediglich einen Button mit dem Titel “Create a Passkey“.

Für die Konfiguration dieser Web Component ist neben einer Project-ID ein sogenannter Association-Token erforderlich. Dieser Token enthält notwendige Informationen über die zu registrierenden Nutzer:innen und muss über einen geeigneten Endpunkt der Corbado-API generiert werden. Auf diese Weise wird eine Verbindung zwischen dem seitens des Services erstellten Schlüsselpaars und dem User hergestellt.

Hingegen sind die Web Components für die Authentifizierung als auch die Verwaltung von Passkeys deutlich umfangreicher in der Konfiguration. Sie übernehmen zudem eine auf Passkeys zugeschnittene Dialogführung, um Nutzer:innen durch die diversen Abläufe zu begleiten. Genauere Details sind der Dokumentation zu entnehmen.

Vergleich der Implementierungsansätze bei der Migration zu Passkeys

Die drei genannten Implementierungsansätze für die Migration zu Passkeys können anhand einer Vielzahl Kriterien unterschieden werden. In der folgenden Tabelle sind einige dieser Kriterien zusammengefasst und gegenübergestellt. Die drei verwendeten Implementierungsansätze sind auf der X-Achse und sieben Kriterien auf der Y-Achse aufgeführt.

Funktionsumfang

Der Ansatz LIB bietet initial den geringsten Funktionsumfang, denn ausschließlich die zwei Passkey-Zeremonien zur Registrierung und Authentifizierung eines Users werden über Funktionen der Libraries abgedeckt. Da die Passkeys selbst gespeichert, aktualisiert oder gelöscht werden müssen, ist es notwendig, auch sämtliche Passkey-Zugriffsfunktionen zu entwickeln. Darüber hinaus muss die gewünschte Benutzungsoberfläche selbst konzipiert und umgesetzt werden. Im Vergleich dazu werden im Ansatz API die Passkeys beim Service verwaltet, was bedeutet, dass auch die Zugriffsfunktionalitäten vom Service bereitgestellt werden. Der Ansatz WCO umfasst die Implementierung der Passkey-Zeremonien, stellt die Passkey-Zugriffsfunktionen bereit und ebenso eine passkey-spezifische Benutzeroberfläche durch die vorgefertigten Web Components.

Entwicklungsaufwand

Als Konsequenz des initial bereitgestellten Funktionsumfangs der Ansätze ergeben sich unterschiedliche Entwicklungsaufwände für die Fertigstellung der Integration. Die Umsetzung ist schätzungsweise in einem SCRUM-basierten Sprint in zwei bis vier Wochen durchführbar. Der Entwicklungsaufwand für den Ansatz LIB befindet sich dabei am oberen Ende, während dieser mit den Ansätzen API oder WCO schätzungsweise um 50 % oder sogar 25 % reduziert werden kann.

Flexibilität

Der Nachteil des erhöhten Entwicklungsaufwands durch den erhöhten eigenständigen Teil, punktet der LIB-Ansatz bei der Flexibilität. Denn je weniger ein Service involviert ist, desto höher die Gestaltungsfreiheit in der Umsetzung. Bei bereits bestehenden komplexen Authentifzierungstrukturen kann dies ein entscheidender Vorteil sein. Im Vergleich zum Ansatz LIB als auch API lässt sich im Ansatz WCO die vorgefertigte Web Component lediglich anhand vordefinierter CSS Klassen an das Design der Anwendung anpassen. Die genauen Abläufe sowie wichtige Dialogführung mit dem User bei der Registrierung sowie Authentifizierung muss übernommen werden und ist nur wenig bis gar nicht anpassbar.

Datensicherheit

Die Verwendung eines Services bedeutet eine eingeschränkte Datensicherheit. Denn im Vergleich zum LIB Ansatz verwalten die Services sämtliche Passkeys. Außerdem erlangen diese Informationen darüber, welche Nutzer sich zu welchen Zeitpunkten einen Passkeys registriert oder damit authentifiziert haben. Die Sicherheit dieser Daten ist dem Service überlassen.

Service-Abhängigkeit

Die Verwendung der Ansätze API und WCO resultiert in einer ernstzunehmenden Abhängigkeit. Denn die Services stellen die essentielle Funktionalität für die Registrierung und Authentifizierung von Nutzer:innen bereit. Fällt der Service aus oder erfüllt nicht sein Leistungsversprechen, könnte Nutzer:innen der Zugang zur Anwendung verwehrt bleiben.

Nutzungsgebühren

Während die Nutzung der Services beziehungsweise Ansätze API und WCO gegenüber dem LIB-Ansatz Entwicklungsaufwand und damit initial Geld einsparen kann, erfordern diese jedoch die Bezahlung fortlaufender Nutzungsgebühren. Diese Nutzungsgebühren bestehen jeweils aus einem fixen und einem variablen Teil, der anhand der Anzahl Monthly Active User (MAU) berechnet wird. Berücksichtigend des unterschiedlichen Funktionsumfangs entspricht der Ansatz API in etwa einem Drittel der Gebühren, die der WCO-Ansatz bzw. -Service fordert.

Session-Management

Ausschließlich der Service mit dem Ansatz WCO unterstützt die Verwaltung von User Sessions. Diese Sessions sind jedoch ausschließlich für Nutzer:innen, die über den Service einen Passkey erstellt haben. Das Session-Management für Nutzer:innen alternativer existierender Authentifizierungsmethoden muss weiterhin selbst übernommen werden.

Handlungsempfehlung

Basierend auf dem Vergleich der Implementierungsansätze lässt sich eine Handlungsempfehlung in Form eines Entscheidungsdiagramms ableiten. Je nach individuellem Ausgangsszenario erweist sich einer der Ansätze als besonders geeignet. Diese Empfehlung dient als Leitfaden und Starthilfe für die Integration von Passkeys in eine Anwendung.

Bei ausreichendem Budget muss als nächstes geklärt werden, ob die Abhängigkeit von der Leistung eines Services akzeptabel ist. Die Leistungserbringung des Services ist von entscheidender Bedeutung, da die Services die Authentifizierung und Registrierung übernehmen und damit wesentliche Bestandteile einer Anwendung bereitstellen. Im schlimmsten Fall könnten sich bei einem Ausfall des Services Nutzer:innen nicht mehr anmelden oder neue Accounts registrieren. Zudem muss man sich auf die Fehlerfreiheit, Sicherheit und Aktualisierungen des Services verlassen können. Falls diese und andere Service-Abhängigkeiten nicht akzeptabel sind, ist nur noch der Ansatz LIB geeignet.

Anschließend gilt es zu klären, ob neben der Service-Abhängigkeit auch die eingeschränkte Datensicherheit akzeptabel ist. Denn sämtliche erstellte Passkeys sowie die Nutzungsverläufe der Passkeys werden bei den Services gespeichert. Zudem müsste im Fall eines Service-Wechsels der Export aller Passkeys angefordert und in einen neuen Service importiert werden. Diese Export- und Importfunktion ist nicht zwingend bei jedem Service verfügbar. Soll die Sicherheit und Kontrolle der Daten ausschließlich unter eigener Beobachtung bestehen, muss der LIB-Ansatz verwendet werden.

Als nächstes sollten die Zeit und die Kapazität für die Entwicklung und die Umsetzung der Integration betrachtet werden. Dabei ergeben sich zwei Pfade, die sich weiter aufteilen.

Zuerst wird der Fall betrachtet, wenn für die Umsetzung tendenziell wenig Zeit und Entwicklungskapazitäten bereitgestellt werden. Dies entspricht dem rechten Pfad im Diagramm. Da die Umsetzung über den Ansatz LIB im Vergleich zu den anderen beiden viele der genannten Ressourcen benötigt, ist die Empfehlung, sich auf die zwei verbleibenden Ansätze API und WCO zu konzentrieren. Unter den beiden Ansätzen wird noch anhand der Flexibilität bei der Integration in bestehende Strukturen unterschieden. Beide Ansätze bieten unterschiedliche Funktionsumfänge, die genutzt werden müssen, um Entwicklungsaufwand einzusparen. Im Gegenzug erfährt der Entwickler eine eingeschränkte Flexibilität durch nur bedingte Anpassungsmöglichkeiten. Sollte die bestehende Authentifizierungslogik sowie die UX/UI der Anwendung eher komplex und individuell gestaltet sein, empfiehlt es sich, den flexibleren API-Ansatz dem weniger flexiblen WCO-Ansatz vorzuziehen.

Wenn tendenziell mehr Zeit und Entwickler:innenkapazität für die Umsetzung zur Verfügung stehen, wird die Entscheidungsfindung entlang des linken Pfades durchgeführt. Falls darüber hinaus Kenntnisse über die relevanten Passkey-Prozesse und die Erstellung einer geeigneten Passkey-UI/UX vorhanden sind, ist aufgrund der Vorteile der uneingeschränkten Entwicklungs- und Gestaltungsfreiheit sowie der Datenkontrolle die Verwendung des LIB-Ansatzes zu bevorzugen. Bei geringen oder fehlenden Kenntnissen empfiehlt es sich, die weitere Differenzierung anhand der Flexibilität der Ansätze bei der Integration von Passkeys in bestehende Strukturen durchzuführen. In Fällen von erhöhter Komplexität der existierenden Authentifizierungslogik und UI/UX, aber genügend Zeit und Entwicklerkapazität, ist die Verwendung des LIB-Ansatzes zu empfehlen, selbst wenn die Kenntnisse gering oder gänzlich fehlend sind. Falls eine erhöhte Flexibilität nicht notwendig ist, wird unter Berücksichtigung bisheriger Entscheidungen die Verwendung des API-Ansatzes als passende Lösung empfohlen.

Best Practices bei der Migration zu Passkeys

Um Passkeys nicht nur mit dem richtigen Implementierungsansatz in die bestehende Anwendung zu integrieren, sondern auch eine Migration zu Passkeys durchzuführen, gilt es insbesondere die fünf folgenden Aspekte zu beachten. Unter der Migration in diesem Kontext wird das Ziel verstanden, sämtliche bestehende Authentifizierungsmethoden und existierende Nutzer komplett auf Passkeys umzuziehen.

1. Einschränkung der Registrierung auf Passkeys
   Es ist wichtig, zu berücksichtigen, dass bei der Migration zu Passkeys die Registrierung neuer Nutzer:innen mit alten Authentifizierungsmethoden ab dem Zeitpunkt der Einführung unterbunden werden sollte. Dadurch kann der Fokus ausschließlich auf die Konvertierung bestehender User ohne Passkeys zu Passkeys gelegt werden. Es gilt zu beachten, dass in den Ansätzen LIB und API die Authentifizierungslogik und Benutzungsoberfläche durch eigene Entwicklungsaufwände entsprechend eingeschränkt werden müssen, während der Ansatz WCO und zugehörige Service Corbado von Beginn an den Migrationsgedanken verfolgen und diese Einschränkung umsetzt.
2. Parallelbetrieb der Authentifzierungsmethoden
   Damit Nutzer:innen übergangsweise die neue Authentifizierungsmethode Passkeys zusätzlich zu bestehenden Methoden nutzen können, ist eine Anpassung der Authentifizierungslogik sowie Benutzungsoberfläche erforderlich. Bei den Ansätzen LIB und API kann die bestehende und neue Authentifizierungslogik und Benutzungsoberfläche uneingeschränkt zusammengeführt werden. Der WCO-Ansatz erfordert hingegen den Einsatz einer vorgefertigten Web Component, was die Zusammenführung der bestehenden und neuen Passkey-Lösung nur eingeschränkt umsetzbar macht.
3. Passkey-Registrierung für angemeldete Nutzer
   Um die Konvertierungsrate der Nutzer:innen zu Passkeys zu erhöhen, ist es wichtig, dass nicht nur während der Registrierung eines Accounts auf die Erstellung eines Passkeys hingewiesen wird. Es sollte auch die Möglichkeit geben, dass User, nachdem sie sich bereits mit einer der bestehenden alternativen Authentifizierungsmethoden angemeldet haben, innerhalb der Anwendung einen Passkey registrieren können. Im Rahmen der LIB- und API-Ansätze ist die Benutzungsoberfläche und die Funktionalität für diese Registrierung selbst zu gestalten und zu implementieren. Im Gegensatz dazu wird bei WCO eine vorgefertigte Web Component bereitgestellt, die eingebunden und anschließend an das Design der Anwendung angepasst werden muss.
4. Einhaltung Passkey-spezifischer Richtlinien
   Als nächstes ist es von entscheidender Bedeutung, die bereits erwähnten spezifischen Richtlinien der FIDO-Alliance für Passkeys bei der Gestaltung des User Interface zu berücksichtigen, um die Benutzungserfahrung zu optimieren und die Konvertierungsrate zu Passkeys zu steigern. Insbesondere sollte der Passkey-First-Ansatz verfolgt werden, um gezielt die Verwendung von Passkeys zu fördern. In der Übergangsphase und des Parallelbetriebs wird den Nutzer:innen durch eine angemessene Dialogführung während der Registrierung und Authentifizierung die Verwendung eines Passkeys besonders nahegelegt.
5. Verwendung einer Frist
   Bei Erreichen eines angemessen festgelegten Schwellenwerts, beispielsweise bei 10-15 % der User, die noch keinen Passkey erstellt haben, könnte eine Frist gesetzt und den Nutzer:innen über die Dialogführung kommuniziert werden. Nach Ablauf dieser Frist können verschiedene Maßnahmen ergriffen werden, wie eine deutliche Benachrichtigung der Nutzer:innen über die Bedeutung von Passkeys oder sogar die Beschränkung des Zugangs ausschließlich auf Passkeys.

Die Zukunft der passwortlosen Authentifizierung

In diesem Blog wurden drei verschiedene Ansätze zur Implementierung von Passkeys erläutert und miteinander verglichen. Daraus wurde eine Handlungsempfehlung abgeleitet, die als Starthilfe und Leitfaden für unterschiedliche Ausgangssituationen dient. Zudem wurden wesentliche Aspekte aufgezeigt, die bei einer vollständigen Migration zu Passkeys berücksichtigt werden sollten.

Obwohl Passkeys mit etwa zwei Jahren noch recht neu ist, existieren bereits zahlreiche etablierte Lösungen zur Umsetzung. Besonders der LIB-Ansatz, der sich ausschließlich auf die Nutzung von Libraries stützt, bietet vielfältige Optionen für nahezu jede Programmiersprache. Zusätzlich bietet die FIDO-Alliance umfassende Ressourcen, die über Funktionsweisen, empfohlene Designrichtlinien und beispielhafte Implementierungen verschiedener Unternehmen informieren.

Trotz der bereits möglichen Integration von Passkeys stellt die ideale Gestaltung der Benutzungsoberfläche sowie die Dialogführung und die gesamte Migration eine erhebliche Herausforderung dar. Hier besteht weiterhin Forschungsbedarf, denn nur durch eine gute Benutzererfahrung werden Nutzer:innen langfristig Passkeys als Ersatz für traditionelle Passwörter akzeptieren.

Ein weiterer wichtiger Aspekt, den es zu untersuchen gilt, ist die Möglichkeit, die Passkey-Funktionalität zu testen. Dies variiert nicht nur zwischen den verschiedenen Libraries, sondern auch zwischen den Implementierungsansätzen. Je mehr Funktionalitäten ein Service bietet, desto eingeschränkter kann das Testen sein. Beispielsweise bietet der LIB-Ansatz durch seine geringe Abhängigkeit von externen Services eine höhere Flexibilität bei der Testgestaltung, während bei servicebasierten Ansätzen wie Hanko oder Corbado spezifische Testumgebungen und -szenarien vorgegeben sein können.

Abschließend ist zu betonen, dass die vorgestellten Ansätze und Services eine Momentaufnahme darstellen. Neue Services und Implementierungsansätze können jederzeit hinzukommen und sollten ebenfalls untersucht und verglichen werden, um die Handlungsempfehlungen bei Bedarf anzupassen. Insgesamt bieten die beschriebenen Ansätze und die Handlungsempfehlung eine solide Grundlage für die Implementierung von Passkeys. Es bleibt jedoch wichtig, die Entwicklungen in diesem Bereich kontinuierlich zu verfolgen und flexibel auf neue Technologien und Best Practices zu reagieren. Nur so kann eine erfolgreiche und nachhaltige Migration zu Passkeys in Webanwendungen gewährleistet werden.