Die passwortlose Authentifizierung verifiziert die Identität eines Benutzenden, ohne dass ein Passwort erforderlich ist. Anstatt von Shared Secrets beruht sie auf dem, was Sie haben (ein Gerät oder ein Einmalcode) oder dem, was Sie sind (Fingerabdrücke, Face ID).

Für Entwicklungsteams vereinfacht die passwortlose Authentifizierung den Anmeldevorgang und trägt dazu bei, die Angriffsfläche durch die Passwortspeicherung und -verwaltung zu reduzieren. Außerdem wird der operative Aufwand bei Passwortrücksetzungen, Account-Sperrungen und die Überwachung von Sicherheitsverletzungen überflüssig gemacht. Passwortlose Methoden verbessern auch die User Experience, indem sie die Password Fatigue und die Anzahl der Support-Anfragen reduzieren.

Laut dem Verizon Data Breach Investigations Report (DBIR) 2025 ist der Missbrauch von Zugangsdaten nach wie vor der häufigste Erstzugriffsvektor bei Sicherheitsverletzungen und macht 22 % der Fälle aus.

Moderne Implementierungen verwenden Standards wie FIDO2, WebAuthn und gerätebasierte Verschlüsselung, um sichere und benutzerfreundliche Authentifizierung zu bieten, bei der Passwörter überflüssig werden.

Passwörter schaffen Sicherheitslücken und betrieblichen Mehraufwand mit Auswirkungen auf Benutzende und Entwicklungsteams. Sie benötigen sicheren Speicher mit adaptiven Hashing-Algorithmen (Argon2, bcrypt, PBKDF2), Überwachung von Sicherheitsverletzungen und Richtlinien für Account-Sperrungen. Passwortbezogene Support-Anfragen machen meist einen großen Teil der Helpdesk-Tickets aus.

Benutzende verwenden Passwörter oft auf mehreren Websites wieder. Die Wiederverwendung von Passwörtern ermöglicht Credential Stuffing-Angriffe, bei denen durch Sicherheitsverletzungen kompromittierte Anmeldedaten wiederverwendet werden, um Zugriff auf andere Services zu erhalten.

Die passwortlose Authentifizierung löst drei zentrale Probleme:

• Sicherheit: Passwörter sind anfällig für Phishing, Credential Stuffing, Replay-Angriffe und Datenbank-Sicherheitsverletzungen. Angreifer können Passwörter durch Social Engineering, Malware oder Datenbankkompromittierungen stehlen. Passwortlose Methoden (v. a. solche mit asymmetrischer Verschlüsselung wie WebAuthn) machen Shared Secrets überflüssig und helfen bei der Beseitigung dieser Angriffsvektoren. Mit WebAuthn werden private Schlüssel niemals aus dem Gerät übertragen, sodass der Diebstahl von Anmeldedaten aus der Ferne praktisch unmöglich ist.
• User Experience: Das Zurücksetzen von Passwörtern führt zu Abbrüchen während kritischer User Journeys und kann zu einer großen Anzahl von Support-Anfragen führen. Benutzende vergessen oft ihre Passwörter, was zu fehlgeschlagenen Anmeldeversuchen und vermehrten Support-Anfragen führt. Die passwortlose Authentifizierung ermöglicht es Benutzenden, sich mit vertrauten Gerätefunktionen (Face ID, Fingerabdrücke) oder einfachen Bestätigungsmethoden (Einmalcodes) zu authentifizieren, was Reibungsverluste reduziert und die Konversionsraten verbessert.
• Aufwand für Entwicklungsteams: Die Verwaltung des Passwortspeichers erfordert die Implementierung von sicherem Hashing mit entsprechendem Aufwand, das Generieren von Salts und die Überwachung auf Sicherheitsverletzungen. Abläufe zum Zurücksetzen von Passwörtern benötigen eine E-Mail-Infrastruktur, Token-Management und Ablaufverwaltung. Die Richtlinien für Account-Sperrungen erfordern die Nachverfolgung fehlgeschlagener Versuche und die Implementierung von Entsperrmechanismen. Die passwortlose Authentifizierung reduziert diese Implementierungsanforderungen erheblich oder macht sie komplett überflüssig, sodass sich Entwicklungsteams auf die Kernfunktionen der Anwendung konzentrieren können.

Die passwortlose Authentifizierung folgt einem einheitlichen Muster:

1. Überprüfung der Identität: Der Benutzende weist nach, dass er die Kontrolle über einen Besitzfaktor (z. B. ein Gerät, einen Hardwareschlüssel, eine E-Mail-Adresse oder ein Telefon) oder einen inhärenten Faktor (z. B. eine Biometrie) hat.
2. Serverseitige Validierung: Der Authentifizierungsserver validiert diesen Nachweis durch kryptografische Signaturen (asymmetrische Methoden) oder zeitlich begrenzte Codes (OTP-Methoden).
3. Token-Ausgabe: Nachdem der Benutzende die Authentifizierung abgeschlossen hat, tauscht der Client den Autorisierungscode am Token-Endpoint mit PKCE aus. Der Token-Endpoint gibt ein ID-Token (mit Identity-Claims) und ein Access Token (für die API-Autorisierung) zurück. Token werden niemals über den Front-Channel zurückgegeben.
4. Session-Aufbau: Die Anwendung richtet eine Session mit sicheren HttpOnly-Cookies oder serverseitigem Session-Speicher ein.

Asymmetrische Methoden (WebAuthn, Passkeys) schützen Anmeldedaten vor Remote-Exfiltration. E-Mail-OTP, SMS-Codes und TOTP übertragen Secrets, die Angreifende abfangen oder kompromittieren können.

WebAuthn (FIDO2)

WebAuthn ermöglicht Browsern und Geräten die Erstellung asymmetrischer Schlüsselpaare. Der private Schlüssel verbleibt auf dem Gerät und wird niemals übertragen. Der Server speichert nur den öffentlichen Schlüssel. Während der Authentifizierung gibt der Server eine Abfrage aus und das Gerät signiert sie mit dem privaten Schlüssel, wodurch der Besitz des Schlüssels nachgewiesen wird, ohne den Schlüssel preiszugeben.

WebAuthn bietet starke kryptografische Garantien mit nativer Plattformintegration in modernen Browsern und Betriebssystemen. Benutzende authentifizieren sich über eingebaute biometrische Sensoren oder Hardware-Sicherheitsschlüssel.

Passkeys

Passkeys sind WebAuthn-Anmeldedaten, die mithilfe von plattformeigenen Anmeldedatenmanagern für das gesamte Geräte-Ökosystem eines Benutzenden synchronisiert werden. Benutzende authentifizieren sich mit Biometrie oder einer Geräte-PIN und können sich geräteübergreifend authentifizieren, indem sie einen QR-Code scannen.

Passkeys gewährleisten die kryptografische Sicherheit von WebAuthn und verbessern gleichzeitig die Benutzerfreundlichkeit durch Synchronisation. Obwohl der Synchronisierungsmechanismus die Angriffsfläche erweitert, wenn der Account des Benutzenden kompromittiert wird, bleibt der zugrundeliegende kryptografische Schutz intakt.

Einmal-Passwörter (OTPs)

• E-Mail-OTPs: Benutzende erhalten Bestätigungscodes per E-Mail. Die Sicherheit hängt von der Sicherheit des E-Mail-Accounts des Benutzenden ab. Am besten geeignet für Consumer-Apps, bei denen Anmeldekonversionen oder Account Recovery-Workflows im Vordergrund stehen.
• SMS-OTPs: Anfällig für SIM-Portierungsangriffe und das Abfangen von Nachrichten. Vermeiden Sie die Verwendung von SMS-OTPs in Szenarien mit maximalen Sicherheitsanforderungen, es sei denn, es ist keine Alternative verfügbar.
• Zeitbasierte Einmal-Passwörter (TOTP): Authentifikator-Apps generieren Codes lokal, wodurch das Abfangrisiko ausgeschlossen wird. TOTP bleibt jedoch anfällig für Phishing- oder Relay-Angriffe in Echtzeit (Man-in-the-Middle). Angreifende, die einen Benutzenden dazu bringen, seinen aktuellen TOTP-Code auf einer schädlichen Website einzugeben, können diesen Code innerhalb des Gültigkeitsfensters von etwa 30 Sekunden sofort an den legitimen Service weiterleiten. TOTP erfüllt die MFA-Anforderungen in einigen Compliance-Szenarien, ist aber nicht Phishing-resistent.

Magic Links

Benutzer erhalten einmalige Authentifizierungslinks per E-Mail. Durch Klicken auf den Link wird die Authentifizierung abgeschlossen. Magic Links vereinfachen die User Experience, sind jedoch abhängig von der E-Mail-Sicherheit und bieten nur begrenzten Phishing-Schutz. Sie sind am besten für Consumer-Apps mit strengen Zeitlimits (oft 5–15 Minuten) und einmaligen Gebrauch geeignet.

Push-Benachrichtigungen

Authentifikator-Apps senden Genehmigungsanfragen an registrierte Geräte. Benutzende wählen „Genehmigen“ oder „Ablehnen“, anstatt einen Code einzugeben. Push-basierte Genehmigungen bieten eine bessere User Experience als TOTP, sind aber weiterhin anfällig für MFA-Fatigue-Angriffe (Multi-Faktor-Authentifizierung), bei denen Angreifende massenhaft Push-Anfragen in der Hoffnung senden, dass Benutzende diese versehentlich genehmigen. Diese Methode eignet sich am besten für Unternehmensumgebungen, in denen Benutzerschulungen und die Erkennung von Anomalien Pflicht sind.

Die passwortlose Authentifizierung umfasst mehrere Methoden, Passkeys stellen eine bestimmte Implementierung dar und MFA beschreibt eine Sicherheitsanforderung. Die folgende Tabelle zeigt die Überschneidungen dieser Konzepte:

Begriff	Definition	Beispiel
Passwortlose Authentifizierung	Jedes Authentifizierungsverfahren ohne Passwort	WebAuthn, Passkeys, Magic Links, TOTP, E-Mail-OTPs
Passkeys	Synchronisierte WebAuthn-Anmeldedaten mit integrierter Benutzerverifizierung	Authentifizierung per Face ID oder Fingerabdruck
MFA	Zwei oder mehr unabhängige Faktoren aus verschiedenen Kategorien	Passwort + TOTP oder nur Passkey (Besitz + biometrisch)

Als einzelner, Phishing-resistenter Authentifikator erfüllen oder übertreffen Passkeys im Allgemeinen die klassischen MFA-Sicherheitsanforderungen, indem sie einen Besitzfaktor (das Gerät mit dem privaten Schlüssel) und einen Benutzervalidierungsfaktor (biometrisch oder PIN) in einem einzigen Schritt kombinieren.

WebAuthn ist die sicherste moderne passwortlose Implementierung, die asymmetrische Verschlüsselung verwendet, um den Diebstahl von Anmeldedaten zu verhindern.

• Registrierung: Die Anwendung (die als vertrauende Partei von WebAuthn fungiert) fordert die Erstellung von Anmeldedaten vom Authentifikator des Benutzenden an. Der Authentifikator generiert ein asymmetrisches Schlüsselpaar, das für die Domain Ihrer Anwendung spezifisch ist. Der Server speichert den öffentlichen Schlüssel, die Anmeldedaten-ID und Metadaten (z. B. die Attestierung des Authentifikators, sofern dies aus Compliance-Gründen erforderlich ist). Der private Schlüssel verlässt niemals das Authentifikator-Gerät. Benutzende können private Schlüssel nicht manuell von Plattform-Authentifikatoren exportieren. Die gerätegebundene Isolierung gewährleistet die grundlegende Sicherheitsgarantie von WebAuthn.
• Authentifizierung: Der Server generiert eine eindeutige kryptografische Abfrage (in der Regel ein Zufallswert). Der Authentifikator signiert diese Anfrage mit dem privaten Schlüssel, der sicher auf dem Gerät gespeichert ist. Der Server validiert die Signatur mithilfe des gespeicherten öffentlichen Schlüssels für diese Anmeldedaten. Der Authentifikator bindet die Signatur kryptografisch an die Domain Ihrer Anwendung, wodurch die signierte Antwort auf jeder anderen Website ungültig wird. Die Domain-Bindung verhindert Phishing-Angriffe, denn selbst wenn ein Benutzender versucht, sich auf einer schädlichen Website zu authentifizieren, funktioniert die signierte Antwort nur für die legitime Domain.
• Token-Ausgabe: Nach erfolgreicher Authentifizierung stellt der Identity-Anbieter Token aus (unter Verwendung sicherer Protokolle wie OpenID Connect und OAuth 2.0 mit PKCE), die in der Regel ein ID-Token für Identity-Claims und ein Access Token für die API-Autorisierung enthalten.
• Session-Aufbau: Die Anwendung richtet eine Session mit sicheren HttpOnly-Cookies mit Secure- und SameSite-Flags oder serverseitigem Session-Speicher ein. Aufgrund von Cross-Site Scripting (XSS)-Schwachstellen sollten Sie Token niemals in localStorage oder sessionStorage speichern. Generieren Sie sofort nach erfolgreicher Authentifizierung eine neue Session-ID, um Session-Fixierungsangriffe zu verhindern.

• Phishing-Resistenz: Bevorzugen Sie WebAuthn oder Passkeys gegenüber OTPs oder Magic Links. Asymmetrische Verschlüsselung bietet eine inhärente Resistenz gegen Phishing durch Domain-gebundene Abfragen.
• Token-Speicher: Verwenden Sie HttpOnly-Cookies mit Secure- und SameSite-Flags oder Backend-Session-Speicher. Vermeiden Sie localStorage und sessionStorage.
• PKCE: Verwenden Sie den Autorisierungscode-Ablauf mit PKCE für alle Client-Typen, um das Abfangen von Autorisierungscodes zu verhindern.
• Anzahlbegrenzung: Wenden Sie Anzahlbegrenzung auf OTP-Endpoints an. Sechsstellige Codes haben nur eine Million Kombinationen. Implementieren Sie Grenzwerte nach IP-Adresse, Benutzenden, Endpoint und Zeitfenster.
• Session-Sicherheit: Regenerieren Sie Session-IDs nach erfolgreicher Authentifizierung, um Session-Fixierungsangriffe zu verhindern. Implementieren Sie ein Inaktivitäts-Timeout (30 Minuten) und einen absoluten Ablauf (8–24 Stunden).
• Wiederherstellung nach Geräteverlust: Stellen Sie sichere Methoden zur erneuten Registrierung bereit. Bei Passkeys authentifizieren sich Benutzende von synchronisierten Geräten aus. Verwenden Sie für nicht synchronisierte Anmeldedaten die verifizierte E-Mail-Wiederherstellung, die administrative Wiederherstellung oder die Trusted-Device-Genehmigung.
• Attestierung: Verwenden Sie die Authentifikator-Attestierung nur, wenn die Einhaltung gesetzlicher Vorschriften eine Hardwareüberprüfung erfordert (z. B. FIPS-Zertifizierung). Die Attestierung erhöht die Komplexität und kann die Akzeptanz verringern.

Methode	Am besten geeignet für	Sicherheitsabwägungen
Passkeys	Consumer-Apps, moderne Browser, häufige Authentifizierung	Synchronisierungsmechanismus hängt von der Sicherheit des Cloud-Accounts ab
WebAuthn (nicht synchronisiert)	Enterprise-Apps, verwaltete Geräte, höchste Sicherheitsanforderungen	Benutzende können sich nicht einfach von neuen Geräten aus authentifizieren
E-Mail-OTPs	Reibungslose Anmeldung, Account-Wiederherstellung	Sicherheit hängt vom E-Mail-Account ab
TOTP	Moderate Sicherheit, akzeptabler Einrichtungsaufwand	Anfällig für Phishing in Echtzeit
SMS-OTPs	Nur für Notfälle	SIM-Portierungsangriffe, Abfangen von Nachrichten

• TOTP als Phishing-resistent behandeln: Angreifende können TOTP-Codes in Echtzeit über Proxy-Angriffe abfangen.
• Unzureichende Anzahlbegrenzung: Angreifende können sechsstellige Codes ohne angemessene Anzahlbegrenzung über mehrere Dimensionen hinweg durch Brute-Force-Angriffe erraten.
• Falscher Anmeldedaten-Speicher: Speichern Sie nur öffentliche Schlüssel. Private Schlüssel dürfen niemals gesichert oder manuell synchronisiert werden.
• Unsichere Wiederherstellungsabläufe: Implementieren Sie eine sichere Neuregistrierung, noch bevor sie benötigt wird. Führen Sie gemeinsam mit Support-Mitarbeitenden Tests durch.
• Unzureichende Session-Sicherheit: Generieren Sie die Sessions-IDs nach der Authentifizierung neu. Ohne Regenerierung können Angreifende, die eine Session-ID fixiert haben, die Session kapern.

Ist passwortlose Authentifizierung sicherer als Passwörter?

Ja, wenn sie korrekt implementiert wird. Passwortlose Methoden reduzieren das Risiko von Phishing, Credential Stuffing und Datenbankkompromittierungen. Die Sicherheit hängt jedoch von der Implementierung ab. E-Mail-OTPs sind nicht von Natur aus sicherer als sichere Passwörter, vorausgesetzt, es gibt entsprechende Richtlinien.

Sind Passkeys eine Art passwortlose Authentifizierung?

Ja. Passkeys sind WebAuthn-Anmeldedaten, die mithilfe von plattformeigenen sicheren Synchronisierungsmechanismen geräteübergreifend synchronisiert werden und die Sicherheit von WebAuthn mit verbesserter Benutzerfreundlichkeit kombinieren.

Kann passwortlose Authentifizierung die MFA-Anforderungen erfüllen?

Ja, wenn es um zwei unabhängige Faktoren geht. Passkeys erfüllen MFA, indem sie den Besitz des Geräts mit biometrischer Überprüfung oder der Geräte-PIN kombinieren. TOTP kann als zweiter Faktor in MFA verwendet werden, ist aber kein MFA an sich.

Was ist, wenn ein Benutzender sein Gerät verliert?

Stellen Sie sichere Methoden zur Neuregistrierung bereit. Bei Passkeys authentifizieren sich die Benutzenden mit einem anderen synchronisierten Gerät. Bei nicht synchronisierten Anmeldedaten verwenden Sie die verifizierte E-Mail-Wiederherstellung mit strenger Überprüfung, die administrative Wiederherstellung oder die Trusted-Device-Genehmigung.

Authentifizieren APIs die Benutzenden direkt?

Nein. In modernen Identity-Architekturen übernimmt der Identity-Anbieter die Authentifizierung und stellt Token aus. APIs validieren Access Token und erzwingen die Autorisierung, nehmen jedoch nicht am Authentifizierungsprozess teil.

Funktioniert passwortlose Authentifizierung in Unternehmensumgebungen?

Ja. Viele Unternehmen kombinieren WebAuthn erfolgreich mit Single Sign-On (SSO) und Geräteverwaltungsfunktionen. In Unternehmensumgebungen werden häufig nicht synchronisierte WebAuthn-Anmeldedaten bevorzugt, die mit risikobasierten Indikatoren an verwaltete Geräte gebunden sind.

Die passwortlose Authentifizierung ist unverzichtbar, um die häufigsten Sicherheitslücken in Ihrer Anwendung zu schließen. Die Implementierung Phishing-resistenter Methoden wie WebAuthn und Passkeys erfordert eine robuste Identity-Plattform.

Die Verwendung eines Services wie Auth0 kann die passwortlose Authentifizierung vereinfachen, sodass Entwicklungsteams sich auf die Kernfunktionen ihrer Anwendung konzentrieren können. In unserer Reihe „Einführung in IAM“ finden Sie weitere Informationen zu Identity and Access Management (IAM).

Mehr erfahren

Diese Materialien dienen nur zur allgemeinen Information. Es liegt in Ihrer Verantwortung, sich mit Blick auf Sicherheit, Datenschutz, Compliance oder geschäftliche Angelegenheiten beraten zu lassen und sich nicht ausschließlich auf die hierin bereitgestellten Informationen zu verlassen.