Passkeys für den Online-Shop: So planen Sie eine passwortlose Anmeldung für Kundinnen und Kunden
Wenn Kundinnen und Kunden in einen Shop zurückkehren, erinnern sie sich vielleicht an das Produkt, aber nicht an das Passwort. Passkeys für den Online-Shop ermöglichen eine Anmeldung mit Bestätigung auf dem Gerät statt der Eingabe eines Geheimnisses, das leicht vergessen oder wiederverwendet werden kann. Das ist kein Knopf, der den Umsatz automatisch steigert: Das Ergebnis hängt von der Zielgruppe, der Gerätekompatibilität, dem Wiederherstellungsszenario und davon ab, wie sorgfältig der Shop die neue Anmeldemethode in das bestehende Konto integriert.
Ein praktikabler Ansatz beginnt nicht mit der Forderung, „alle Passwörter abzuschaffen“, sondern mit einem gezielten Szenario: Registrierten Kundinnen und Kunden erlauben, einen Passkey hinzuzufügen, den Erfolg der Anmeldung und der Wiederherstellung des Zugangs prüfen und anschließend die Nutzung ausweiten. Im Folgenden finden Sie Kriterien, Prüfschritte vor dem Start, Risiken, Zeitrahmen und Kostenbestandteile einer solchen Einführung.
Was Passkeys im Shop konkret verändern
Bei der gewohnten Anmeldung prüft der Server ein Passwort oder einen danach erhaltenen Code. Bei WebAuthn kommuniziert der Browser mit einem Authentifikator: Der Server stellt eine einmalige Challenge aus, das Gerät signiert sie mit einem privaten Schlüssel, und der Server prüft die Signatur mit dem öffentlichen Schlüssel, der dem Konto zugeordnet ist. Ein Passwort oder ein daraus abgeleitetes Geheimnis wird bei diesem Vorgang nicht benötigt. Das Protokoll bindet die Anmeldedaten an die entsprechende Webdomain und verringert dadurch das Risiko einer Nutzung durch eine Phishing-Website, beseitigt jedoch nicht alle Arten von Betrug oder einer Kompromittierung des Kontos.
Womit Sie anfangen sollten: Szenario und Nutzen bestimmen
Nicht jeder Shop sollte mit einer passwortlosen Anmeldung beginnen. Wenn die meisten Bestellungen als Gast aufgegeben werden und das persönliche Konto nur selten benötigt wird, kann es zunächst sinnvoller sein, den Gast-Checkout zu vereinfachen. Kehren Kundinnen und Kunden dagegen häufig zurück, verwalten sie Adressen, sehen ihre Bestellhistorie ein oder nutzen B2B-Konditionen, kann eine bequeme erneute Anmeldung ein spürbares betriebliches Problem lösen.
Architekturentscheidungen: eigene Implementierung oder Identitätsdienst
Ein Shop kann WebAuthn in der eigenen Infrastruktur implementieren oder einen Identitätsanbieter nutzen, der Passkeys unterstützt. Die Wahl hängt davon ab, wer die Anmeldung bereits verwaltet, welche Systeme eine bestätigte Identität erhalten müssen, ob mehrere Shops/Domains erforderlich sind und wer den Sicherheitsablauf betreut. Vergleichen Sie nicht nur, ob es eine Schaltfläche gibt, sondern den gesamten Lebenszyklus des Kontos.
| Kriterium | Eigene WebAuthn-Implementierung | Identitätsmanagementdienst |
|---|---|---|
| Kontrolle über die Logik | Flexible Abstimmung auf Profil, Warenkorb und Geschäftsregeln | Weniger eigene Infrastruktur, aber die Logik ist durch Funktionen und Tarife des Dienstes begrenzt |
| Verantwortung | Das Team ist für Serverprotokoll, Schutz, Protokolle und Aktualisierungen verantwortlich | Ein Teil der Funktionen liegt beim Anbieter; die Verantwortungsgrenzen müssen festgelegt werden |
| Integrationen | Spezielle CRM-/ERP-Systeme und mehrere Storefront-Szenarien lassen sich berücksichtigen | Protokolle, SSO, Datenexport und Verhalten bei Ausfällen müssen geprüft werden |
| Betriebskosten | Mehr Aufwand für Konzeption, Entwicklung, Tests und laufende Betreuung | Die Entwicklung kann kürzer dauern, hinzu kommen jedoch Abonnement, nutzungsabhängige Tarife und Ausstiegskosten |
| Geeignet für | Komplexes Profilmodell, besondere Kontrollanforderungen und vorhandene Fachkompetenz | Ein standardisierter Ablauf wird benötigt und die Organisation möchte das Protokoll nicht selbst betreuen |
Registrierung und tägliche Anmeldung gestalten
Ein Passkey wird üblicherweise einem bereits bestätigten Profil hinzugefügt. Kundinnen und Kunden melden sich mit der bestehenden Methode an, öffnen die Sicherheitseinstellungen, erhalten eine verständliche Erklärung, erstellen einen Schlüssel und bekommen die Bestätigung, dass er registriert wurde. Bieten Sie nicht an, während des Bezahlvorgangs unbemerkt einen Schlüssel zu erstellen, und werten Sie einen zufälligen Klick im Systemdialog nicht als bewusste Zustimmung zu einer Änderung der Anmeldemethode.
Registrierung nach der Anmeldung
Prüfen Sie vor dem Erstellen des Schlüssels erneut, ob die Sitzung der richtigen Kundin oder dem richtigen Kunden gehört und ausreichend abgesichert ist. Zeigen Sie die Aktion nur im passenden Kontext an, zum Beispiel im Profil, und erklären Sie, dass der Schlüssel über den Zugangsdatenmanager des Geräts oder einen anderen kompatiblen Mechanismus verfügbar sein wird. Nach der Antwort des Authentifikators prüft der Server die Challenge, den Origin, die RP-ID, den Zeremonientyp und weitere Anforderungen der Spezifikation und speichert anschließend die erforderlichen Credential-Daten. Verlassen Sie sich nicht allein darauf, dass der Dialog im Browser erfolgreich abgeschlossen wurde.
Anmeldung und kompatibler Ersatzweg
Die Wiederherstellung des Zugangs ist Teil des Produkts, keine Ausnahme
Passkeys können innerhalb eines Zugangsdatenmanagers zwischen Geräten synchronisiert oder an ein bestimmtes Gerät gebunden sein. Im ersten Fall kann die Wiederherstellung einfacher sein, doch der Shop kontrolliert die Synchronisierung nicht und darf sie nicht als garantiert ansehen. Im zweiten Fall kann ein verlorenes Gerät bedeuten, dass dieser Schlüssel nicht mehr verfügbar ist. Die FIDO Alliance unterscheidet diese Szenarien; die Wahl sollte den Risiken und Bedürfnissen der Zielgruppe entsprechen und nicht der Annahme, alle Schlüssel seien gleich.
Planen Sie mehrere unabhängige Wege: einen weiteren registrierten Schlüssel, eine verifizierte Wiederherstellung über einen bestehenden Kanal, eine erneute Identitätsprüfung für einen sensiblen Vorgang oder Hilfe durch den Support nach einem genehmigten Verfahren. Ein Link per E-Mail beweist für sich genommen nicht, dass die richtige Person die Adresse kontrolliert, wenn sich die E-Mail-Adresse geändert hat oder das Konto übernommen wurde. Erlauben Sie dem Support nicht, den Schutz manuell allein aufgrund der Kenntnis einer Bestellnummer oder öffentlich zugänglicher Daten abzuschalten.
Prüfung vor dem Start: ein kontrollierter Pilot
Führen Sie die Funktion zunächst in einer Testumgebung und mit einer begrenzten Gruppe ein, die freiwillig an der Prüfung des Ablaufs teilnimmt. Der Pilot muss nicht nur eine erfolgreiche Registrierung, sondern auch Abbruch, Wiederholung, Gerätewechsel und Supportanfragen abdecken. Bereiten Sie einen Plan zur Rückkehr zum bisherigen Verfahren vor, falls die Integration die Anmeldung blockiert oder doppelte Profile erzeugt.
- Ausgangslage festhalten. Messen Sie erfolgreiche und fehlgeschlagene Anmeldungen, Passwortzurücksetzungen, Gast- und Folgekäufe sowie Supportanfragen. Gliedern Sie die Kennzahlen nach Gerät und Kanal, ohne Daten zu erfassen, die für den Zweck nicht erforderlich sind.
- Protokoll und Domains prüfen. Überprüfen Sie HTTPS, Origin, RP-ID, Challenge, die serverseitige Antwortprüfung, die Sitzungsdauer und das Verhalten verschiedener Subdomains. Testen Sie den Ablauf separat für jede Domain, auf der sich Kundinnen und Kunden anmelden müssen.
- Eine Gerätematrix erstellen. Testen Sie die für Ihre Zielgruppe relevanten mobilen und Desktop-Browser, mehrere Arten von Authentifikatoren, den privaten Modus sowie eine Umgebung, in der Passkeys deaktiviert oder nicht verfügbar sind. Halten Sie die Browserversion und den vorgesehenen Ersatzweg fest.
- Negativszenarien durchspielen. Abbruch, falsche oder abgelaufene Challenge, doppelte Antwort, Ausfall des Identitätsdienstes, Geräteverlust, Widerruf eines Schlüssels, Änderung der Konto-E-Mail-Adresse und Wiederherstellung über den Support müssen verständlich enden, ohne den Zugang zu einem fremden Profil zu ermöglichen.
- Den E-Commerce-Prozess prüfen. Durchlaufen Sie Katalog, Warenkorb, Gutschein, Checkout, Zahlung, Bestellbestätigung, Rückkehr zur Website und erneute Anmeldung. Vergewissern Sie sich, dass eine Änderung der Anmeldemethode den Warenkorb nicht löscht und keine zweite Zahlung auslöst.
- Sicherheit und Protokollierung prüfen. Stellen Sie sicher, dass der Server die kryptografische Antwort und die Parameter der Zeremonie prüft und dass Passkey-Daten nicht in Protokolle, Analysen oder URLs gelangen. Prüfen Sie Versuchsbeschränkungen und Signale zur Erkennung verdächtiger Aktivitäten.
- Ergebnisse mit der Basis vergleichen. Analysieren Sie abgeschlossene Anmeldungen, Abbrüche, den Wechsel zur Ersatzmethode, Bestellungen und die Supportbelastung. Schreiben Sie eine Veränderung der Conversion nicht allein Passkeys zu, wenn sich gleichzeitig Preise, Kampagnen oder der Checkout geändert haben.
Risiken und Einschränkungen, die Sie vor der Entscheidung berücksichtigen sollten
Ein Schlüssel ist an den Domain-Kontext gebunden. Wenn der Shop mehrere Domains oder Länder-Websites betreibt, sollten Sie nicht davon ausgehen, dass eine Registrierung automatisch auf jeder Domain funktioniert. Sie müssen die Domainarchitektur festlegen, die gemäß Spezifikation unterstützten Mechanismen für verknüpfte Origins prüfen und auf kompatiblen Browsern testen. Ein Fehler bei der RP-ID kann Kundinnen und Kunden von der Anmeldung ausschließen; planen Sie Domainänderungen daher als eigenes technisches Risiko.
Zeitrahmen und Kostenbestandteile
Der Zeitplan hängt nicht nur vom Schreiben des Codes ab. Einfluss haben der Zustand der aktuellen Authentifizierung, die Zahl der Storefront-Domains, die Verknüpfung von Profilen, Integrationen mit Kundendiensten, eine verfügbare Testumgebung und die Möglichkeit, echte Geräte zu prüfen. Ein Pilot mit einem Szenario und einem sauberen Kontomodell erfordert einen anderen Aufwand als eine Einführung in mehreren Shops mit unterschiedlichen Regeln, CRM und Treueprogramm.
Planen Sie die Arbeiten in dieser Reihenfolge: Prüfung des aktuellen Anmeldeverfahrens und der Daten; Bedrohungsmodell und Anforderungen; UX-Prototyp und Erklärungstexte; Auswahl einer Bibliothek oder eines Anbieters; server- und clientseitige Integration; Schlüsselverwaltung und Wiederherstellung; Analytik; Testmatrix; Pilot; Monitoring und Schulung des Supports. Die Abhängigkeit von einem externen Dienst, eine juristische Prüfung, der Zugang zu Testgeräten und entdeckte doppelte Profile können den Plan verändern.
Das Budget umfasst Analyse und Konzeption, Entwicklung, Lizenzen oder Anbietertarife, Integrationen mit CMS/CRM/ERP, Kompatibilitätstests, Sicherheitsprüfung, Vorbereitung des Supports, Analytik und laufende Betreuung. Berücksichtigen Sie im Vergleich auch die Kosten für die Unterstützung mehrerer Anmeldemethoden, Monitoring, die Reaktion auf Vorfälle und einen möglichen Anbieterwechsel. Ohne Bewertung der Plattform, des Integrationsumfangs, der Verfügbarkeitsanforderungen und der Wiederherstellungsrichtlinien lässt sich kein seriöser allgemeingültiger Preis nennen.
Fazit: Führen Sie Passkeys entsprechend der Prozessreife ein
Beginnen Sie mit einem kontrollierten Pilot: Lassen Sie eine alternative Anmeldemethode bestehen, prüfen Sie die wichtigsten Geräte, erfassen Sie Kennzahlen und legen Sie vorab Abbruchkriterien fest. Bevor Sie die Einführung ausweiten, lassen Sie das Sicherheitsmodell von einer Fachperson prüfen und geben Sie dem Support ein Wiederherstellungsverfahren an die Hand. Zur Bewertung von Architektur, Integrationen und Startplan besprechen Sie mit GL.ua die Entwicklung oder Weiterentwicklung eines Online-Shops. Als Referenz für die Prüfung dient die WebAuthn-Level-3-Spezifikation.
Nur ein Schritt zu Ihrer perfekten Website



