Passkeys in Webanwendungen: Anmelden ohne Passwort
Für die meisten Kundenportale sind Passkeys die bessere Anmeldung: Sie schützen gegen Phishing und gestohlene Passwörter und ersparen Ihren Nutzern das Merken. Am besten führen Sie Passkeys als zusätzliche Anmeldeart neben dem bestehenden Login ein, nicht als harten Wechsel.
Der Grund liegt im Verfahren: Ein Passkey ist ein Schlüsselpaar statt eines Passworts. Der geheime Teil bleibt auf dem Gerät des Nutzers, Ihre Anwendung speichert nur den öffentlichen Teil. Eine gefälschte Login-Seite bekommt deshalb nichts Verwertbares, und ein Datenleck auf Ihrem Server verrät keine Zugangsdaten. Die folgenden Abschnitte zeigen, wie das funktioniert, was Ihre Nutzer brauchen und wie Sie Passkeys in ein bestehendes Kundenportal mit vielen Nutzern einführen.
Das Verfahren
Wie Passkeys funktionieren
Ein Passkey ersetzt das Passwort durch ein Schlüsselpaar. Beim Einrichten erzeugt das Gerät des Nutzers zwei Schlüssel: Der private Schlüssel bleibt auf dem Gerät oder im geschützten Schlüsselbund, der öffentliche Schlüssel wird in Ihrer Anwendung gespeichert. Bei jeder Anmeldung schickt der Server eine zufällige Aufgabe, das Gerät unterschreibt sie mit dem privaten Schlüssel, und der Server prüft die Unterschrift mit dem öffentlichen Schlüssel.
Der Nutzer merkt davon wenig. Er bestätigt die Anmeldung so, wie er sein Smartphone oder seinen Laptop entsperrt: mit Fingerabdruck, Gesichtserkennung oder Geräte-PIN. Diese biometrischen Daten verlassen das Gerät nicht, Ihr Server sieht sie nie.
Technisch beruht das Verfahren auf zwei offenen Standards: WebAuthn, der Browser-Schnittstelle des W3C, und CTAP der FIDO Alliance für die Verbindung zu Smartphones und Sicherheitsschlüsseln. WebAuthn Level 2 ist seit 2021 eine W3C-Empfehlung, Level 3 lag im Mai 2026 als Candidate Recommendation vor. Für Ihre Webanwendung heißt das: Sie bauen auf einen Standard, den alle großen Browser und Betriebssysteme unterstützen, und nicht auf die Schnittstelle eines einzelnen Anbieters.
Aktualisierung vom 02.11.2026: Seit dem 25.08.2026 ist WebAuthn Level 3 eine W3C-Empfehlung (Recommendation). An der Funktionsweise für Ihre Anwendung ändert das nichts.
Wichtig für die Authentifizierung: Jeder Passkey ist an die Domain Ihrer Anwendung gebunden. Das Gerät gibt ihn nur auf genau dieser Domain heraus. Für ein Portal mit vielen Nutzern ist das der entscheidende Unterschied zum Passwort, das jeder überall eintippen kann.
Vergleich
Vorteile gegenüber Passwort und SMS-Code
Der größte Vorteil von Passkeys in einer Webanwendung ist der Schutz gegen Phishing. Eine nachgebaute Login-Seite unter einer fremden Domain bekommt keine gültige Anmeldung, weil das Gerät den Passkey dort nicht anbietet. Das BSI beschreibt Passkeys deshalb als weitgehend immun gegen Phishing und empfiehlt, sie zu nutzen, wo vertrauenswürdige Dienste sie anbieten.
Im Vergleich der gängigen Verfahren:
Passwort: kann erraten, wiederverwendet, abgefischt oder bei einem Datenleck eines anderen Dienstes erbeutet werden. Ihr Server muss Hashes sicher speichern und gegen Durchprobieren absichern.
Passwort plus SMS-Code: deutlich besser, aber der Code lässt sich auf einer gefälschten Seite mit abfangen und weiterreichen. Dazu kommen SMS-Kosten und Zustellprobleme im Ausland.
Passwort plus App-Code (TOTP): sicherer als SMS, aber ebenfalls abfischbar, und für Nutzer ein zusätzlicher Schritt bei jeder Anmeldung.
Passkey: nichts zu merken, nichts abzutippen, nichts, was ein Angreifer auf einer fremden Seite abgreifen kann. Ihr Server speichert nur öffentliche Schlüssel, ein Datenleck verrät keine Zugangsdaten.
Ein Passkey vereint dabei Besitz (das Gerät) und Wissen oder Biometrie (Entsperren). Er erfüllt damit die Idee der Multi-Faktor-Authentifizierung in einem einzigen Schritt. Für den Support bedeutet das weniger Anfragen zum Zurücksetzen von Passwörtern. Ob und wie stark diese Anfragen sinken, hängt von Ihrem Portal ab; das lässt sich nach der Einführung im eigenen Ticketsystem messen.
Ein Passkey ersetzt keine Pflege der übrigen Anwendung. Sicherheitsupdates für Framework und Pakete bleiben nötig, wie wir im Beitrag über Patch-Disziplin bei kleinen Updates beschreiben.
Voraussetzungen
Was Ihre Nutzer dafür brauchen
Ihre Nutzer brauchen ein aktuelles Gerät mit Bildschirmsperre und einen aktuellen Browser. Passkeys funktionieren mit aktuellen Versionen von iOS, iPadOS, macOS, Android und Windows sowie mit Chrome, Safari, Edge und Firefox.
Es gibt zwei Arten, wie Passkeys gespeichert werden:
Synchronisierte Passkeys liegen im Schlüsselbund des Betriebssystems oder eines Passwortmanagers und stehen auf allen Geräten des Nutzers bereit. Das ist der Normalfall bei Privatgeräten.
Gerätegebundene Passkeys liegen auf einem Hardware-Sicherheitsschlüssel oder einem einzelnen Gerät. Sie sind für Administratoren und besonders schützenswerte Zugänge interessant. Das BSI rät hier zu einem zweiten Schlüssel als Reserve.
Am fremden Rechner, etwa im Büro eines Kunden, zeigt der Browser einen QR-Code. Der Nutzer scannt ihn mit dem Smartphone, das per Bluetooth in der Nähe sein muss, und bestätigt dort. Für Firmenrechner mit verwalteten Browsern gehört ein Test vor den Start, weil Richtlinien einzelne Wege sperren können.
Einführung
Einführung neben bestehenden Logins
Passkeys führen Sie am besten schrittweise ein: zuerst als zusätzliche Option, später als bevorzugter Weg. Ein harter Wechsel an einem Stichtag schließt Nutzer aus, deren Geräte oder Firmenrichtlinien noch nicht mitspielen.
Ein Ablauf in vier Schritten:
Anbieten nach der Anmeldung: Nach einem erfolgreichen Login mit Passwort fragt das Portal, ob der Nutzer einen Passkey anlegen möchte. Ein Klick, eine Bestätigung am Gerät, fertig.
Verwalten im Profil: Nutzer sehen ihre Passkeys mit Gerätenamen und Datum, können weitere anlegen und alte löschen.
Passkey zuerst anbieten: Die Login-Seite schlägt den Passkey automatisch vor (der Browser zeigt ihn im Eingabefeld an), das Passwortfeld bleibt als zweiter Weg.
Passwort optional machen: Wer mindestens einen Passkey hat, kann das Passwort abschalten. Für die Wiederherstellung bleibt ein geprüfter Weg über die bestätigte E-Mail-Adresse.
Für Laravel-Anwendungen ist der technische Teil überschaubar. Seit April 2026 kann Laravel Fortify Passkeys als Funktion einschalten. Fortify nutzt dafür das Composer-Paket laravel/passkeys für die Serverseite, für den Browser gibt es ein eigenes JavaScript-Paket (@laravel/passkeys). Daneben gibt es Community-Pakete, die schon länger im Einsatz sind. Welches davon passt, hängt davon ab, ob Ihre Anwendung Fortify bereits nutzt.
Wer ein Portal für viele Kunden betreibt, plant zusätzlich die Domain-Frage. Technisch steckt dahinter die Relying-Party-ID, die beim Anlegen jedes Passkeys festgeschrieben wird. Wird sie auf portal.example.de gesetzt, funktionieren die Passkeys später nicht unter www.example.de. Wird sie auf example.de gesetzt, gelten sie für alle Subdomains. Ein späterer Umzug auf eine neue Domain bedeutet meist, dass alle Nutzer ihre Passkeys neu anlegen müssen. Diese Entscheidung gehört deshalb vor den Start. Welche weiteren Sicherheitsmaßnahmen wir in Projekten umsetzen, steht auf unserer Seite zu Sicherheit und Compliance.
Kurz beantwortet
Häufige Fragen
-
Bei synchronisierten Passkeys liegt eine Kopie im Konto des Anbieters, etwa im iCloud-Schlüsselbund oder im Google Passwortmanager. Auf dem neuen Gerät steht der Passkey nach der Anmeldung im Konto wieder bereit. Für Nutzer ohne Sicherung braucht Ihr Portal einen geprüften Weg zur Wiederherstellung, zum Beispiel per bestätigter E-Mail-Adresse und anschließendem Anlegen eines neuen Passkeys.
-
Aktuelle Versionen von iOS, Android, macOS und Windows sowie die gängigen Browser unterstützen Passkeys. Am fremden PC meldet sich der Nutzer per QR-Code mit dem Smartphone an, das per Bluetooth in der Nähe sein muss. Ältere Geräte und Firmenrechner mit strengen Richtlinien sind der Grund, warum ein zweiter Anmeldeweg vorerst bleiben sollte.
-
Nein. WebAuthn ist ein offener Browser-Standard, den Ihre eigene Anwendung direkt umsetzen kann. Gespeichert wird pro Nutzer nur ein öffentlicher Schlüssel mit Kennung. Ein externer Anbieter kann sinnvoll sein, wenn ohnehin ein zentrales Login für mehrere Anwendungen geplant ist.
Passkeys für Ihr Portal planen
Wir prüfen Ihren bestehenden Login, schlagen einen Einführungsweg vor und bauen Passkeys in Ihre Laravel-Anwendung ein.
Nachweise
Quellen und Stand
Geprüft am 02.11.2026: Stand der W3C-Standards und der Laravel-Pakete.
Artikel teilen