Was ist passwortlose Authentifizierung?

Passwortlose Authentifizierung ist ein Anmeldemodell, das die Identität über einen Geräteschlüssel oder Biometrie statt über ein gemerktes Geheimnis prüft. In der Sprache der Faktoren: Sie entfernt den Wissensfaktor und authentifiziert über den Besitzfaktor und über das, was Sie sind – und in den stärksten Varianten existiert überhaupt kein gemeinsames Geheimnis: Der Server speichert einen öffentlichen Schlüssel, der private verlässt Ihr Gerät nie, und es gibt nichts zu erphishen, durchzuprobieren oder in großem Stil abzugreifen. Passwörter halten sich nicht, weil sie gut sind, sondern weil sie installiert sind; passwortlos ist die Migration, die nun endlich in der Breite läuft.

Das Wichtigste in Kürze

Die WebAuthn-Ceremony, entzaubert

Die Mechanik hinter jeder Passkey-Abfrage – zwei Ceremonies, keine Geheimnisse auf der Leitung:

REGISTRIERUNG                             ANMELDUNG
1 Server sendet eine zufällige Challenge  1 Server sendet eine frische Challenge
2 navigator.credentials.create()          2 navigator.credentials.get()
3 Gerät erzeugt ein Schlüsselpaar,        3 lokale Entsperrung per Biometrie/PIN,
  Biometrie oder PIN schützen es            das Gerät SIGNIERT die Challenge
4 öffentlicher Schlüssel → Server;        4 Server prüft mit dem gespeicherten
  der private bleibt auf dem Gerät          öffentlichen Schlüssel → Session

Das Credential ist an den ORIGIN gebunden: Eine nachgemachte Domain
erhält eine Signatur, die sich nirgends verifizieren lässt. Diese
Eigenschaft – nicht die Biometrie – meint "Phishing-resistent".

Die sanftere Auffahrt, die die meisten Apps zuerst ausliefern – Magic Links, bei denen das Postfach der Faktor ist:

// JavaScript / Node.js — Back4app JS SDK
// Magic link via Cloud Code: possession of the inbox is the factor
// 1 · Request: generates a single-use token, emails the link
await Parse.Cloud.run('requestMagicLink', { email: '[email protected]' });

// 2 · The link opens the app with the token; exchange it for a session
const { sessionToken } = await Parse.Cloud.run('redeemMagicLink', {
  token: tokenFromLink, // single-use, expires in 15 minutes
});
await Parse.User.become(sessionToken); // logged in — no password exists

// Flutter / Dart — Back4app Flutter SDK
// Magic link via Cloud Code: possession of the inbox is the factor
// 1 · Request: generates a single-use token, emails the link
await ParseCloudFunction('requestMagicLink')
    .execute(parameters: {'email': '[email protected]'});

// 2 · The deep link opens the app with the token; exchange for a session
final result = await ParseCloudFunction('redeemMagicLink')
    .execute(parameters: {'token': tokenFromLink}); // single-use, 15 min
// Adopt the returned session token — logged in, no password exists

// iOS / Swift — Back4app Swift SDK
// Magic link via Cloud Code: possession of the inbox is the factor
// 1 · Request: generates a single-use token, emails the link
_ = try await Cloud.run(name: "requestMagicLink",
                        parameters: ["email": "[email protected]"])

// 2 · The universal link opens the app with the token; exchange for a session
let result = try await Cloud.run(name: "redeemMagicLink",
                                 parameters: ["token": tokenFromLink])
try await User.become(sessionToken: result["sessionToken"] ?? "")
// logged in — no password exists

// Android / Kotlin — Back4app Android SDK
// Magic link via Cloud Code: possession of the inbox is the factor
// 1 · Request: generates a single-use token, emails the link
ParseCloud.callFunction<Map<String, Any>>(
    "requestMagicLink", mapOf("email" to "[email protected]"))

// 2 · The deep link opens the app with the token; exchange for a session
val result = ParseCloud.callFunction<Map<String, Any>>(
    "redeemMagicLink", mapOf("token" to tokenFromLink)) // single-use, 15 min
ParseUser.becomeInBackground(result["sessionToken"] as String)
// logged in — no password exists

Passkeys vs. Magic Links vs. OTP: die Verfahren im Ranking

Jedes passwortlose Verfahren erbt die Sicherheit von etwas anderem – die Tabelle sagt, wovon:

Die Linie, auf die es ankommt, verläuft zwischen den ersten beiden Zeilen und dem Rest: Codes, Links und Bestätigungen lassen sich allesamt über einen Live-Phishing-Proxy weiterleiten; an den Origin gebundene Signaturen nicht – dieselbe Trennlinie, die das Ranking der Verfahren im MFA-Artikel zieht, denn es ist dieselbe Linie.

Synchronisiert oder gerätegebunden: der eigentliche Trade-off

Passkeys teilen sich in zwei Verwahrmodelle, und der Unterschied ist Richtlinie, nicht Wortklauberei. Synchronisierte Passkeys liegen in einem Credential Manager und replizieren Ende-zu-Ende-verschlüsselt über die Geräte eines Benutzers – das Telefon zu verlieren ist damit ein Nicht-Ereignis, weshalb die Verbreitung bei Verbrauchern endlich in Gang kam; der Preis ist, dass das Sync-Konto zum Kronjuwel wird, bewacht von seinen eigenen Wiederherstellungswegen. Gerätegebundene Schlüssel (Hardware-Sicherheitsschlüssel, per Attestation bestätigte Authentifikatoren im Unternehmen) verlassen die Hardware nie – die Wahl mit hoher Zusicherung für Administratoren und regulierte Zugriffe, mit “einen Ersatz registrieren” als komplettem Wiederherstellungsplan. Die aktuellen Empfehlungen des NIST haben die Debatte für den Massenmarkt entschieden: Synchronisierte Authentifikatoren sind auf den üblichen Vertrauensniveaus zulässig, gerätegebundene bleiben der obersten Stufe vorbehalten.

Das Problem der Wiederherstellung, erneut

Passwortlos schärft die älteste Regel der Authentifizierung: Ein Konto ist nur so stark wie sein schwächster Wiederherstellungsweg. Eine Passkey-Anmeldung mit E-Mail-OTP als Rückfall ist aus Sicht eines Angreifers eine E-Mail-OTP-Anmeldung mit ein paar Zwischenschritten. Für einen gerätegebundenen Schlüssel gibt es kein “Zurücksetzen” – von Entwurf wegen –, also verlagert sich die Disziplin nach vorn: bei der Einrichtung zwei oder mehr Authentifikatoren auf getrennten Geräten registrieren, Offline-Wiederherstellungscodes ausgeben, Rückfallverfahren als Sicherheitsentscheidung behandeln statt als Support-Bequemlichkeit und das Entfernen eines Authentifikators zu einem Schritt mit erhöhter Prüfung machen – protokolliert und mit Benachrichtigung. Deployments, die das überspringen, lernen es über ihren Helpdesk neu.

Nicht gegen MFA – eine Verschmelzung

Die Gegenüberstellung “passwortlos vs. MFA” auf Anbieter-Vergleichsseiten ist ein falsches Entweder-oder. MFA bedeutet mehrere Faktorkategorien; passwortlos bedeutet kein gemerktes Geheimnis. Ein Passkey, der per Fingerabdruck entsperrt wird, ist beides: Besitz des Geräts plus Inhärenz beim Entsperren – Multi-Faktor in einer Geste, wobei das erphishbare Element gelöscht statt ergänzt wird. Die praktische Folge: Organisationen wählen nicht zwischen beidem; sie wechseln von “Passwort + zweiter Faktor” zu “Passkey”, was auf derselben Kurve ein strikt stärkerer Punkt ist.

Typische Anwendungsfälle

• Anmeldung in Consumer-Apps – Passkeys als beworbener Weg, Magic Links als reibungsarmer Rückfall.
• Handel mit wiederkehrenden Besuchen – wo Reibung bei der Anmeldung messbarer Umsatz ist, verdient die Ein-Gesten-Anmeldung ihr Geld.
• Zugriff für Mitarbeitende – Phishing-resistente Authentifikatoren als Richtlinie für Administratoren und Rollen mit hohen Rechten.
• Produkte ohne Passwort von Anfang an – Onboarding per E-Mail-Link oder OTP, ohne je ein Passwortfeld auszuliefern.
• Momente mit erhöhter Prüfung – eine Passkey-Ceremony als erneute Authentifizierung vor Zahlungen, Löschungen und Schlüsselexporten.

Sollten Sie passwortlos gehen? Entscheidungsmatrix

Grenzen und Trade-offs

• Die Abdeckung ist nicht universell. Noch nicht jede Website, jeder Browser und jeder Unternehmens-Stack unterstützt Passkeys; Passwörter bleiben als Kompatibilitätsgerüst bestehen – weshalb Koexistenz besser ist als ein harter Schnitt.
• Das Ökosystem hält die Schlüssel. Synchronisierte Passkeys delegieren die Verwahrung an die Credential Manager der Plattformen – eine Abhängigkeit bei Verfügbarkeit und Vertrauen, die Sie erben statt betreiben.
• Die Wiederherstellung ist das eigentliche Projekt. Die stärkste Ceremony mit einem schwachen Reset-Pfad ist Theater; planen Sie die UX der Registrierung und die Richtlinie für Rückfallwege ein, nicht nur die WebAuthn-Integration.
• Schwächeres Passwortlos bleibt schwächer. Magic Links und SMS entfernen das Passwort, ohne Phishing-Resistenz hinzuzufügen – ein Fortschritt, nicht das Ziel.
• Die Support-Modelle ändern sich. Aus “Passwort vergessen” werden “Gerät verloren”-Tickets; Helpdesks brauchen Prüfverfahren, die nicht zum neuen Einfallstor für Social Engineering werden.

Passwortlos mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Passwortlos ist hier ein Muster, das Sie aus Plattformbausteinen zusammensetzen, und die Code-Tabs zeigen das kanonische: einen Magic-Link-Ablauf, gebaut aus zwei Cloud-Code-Funktionen – requestMagicLink erzeugt ein einmalig verwendbares Token mit kurzer Ablaufzeit, speichert es am Benutzer und verschickt den Link per E-Mail; redeemMagicLink validiert es serverseitig und liefert ein Session Token zurück, das das SDK übernimmt, sodass der Client nie mit Zugangsdaten hantiert. Über Links hinaus binden die Custom-Auth-Adapter von Back4app OTP- und Passkey-Anbieter an denselben authData-Mechanismus an, der auch das Social Login trägt – ein Benutzerobjekt, mehrere Anmeldeverfahren, pro Benutzer verknüpf- und lösbar, also die Wiederherstellungsdisziplin (mehrere registrierte Verfahren) als Datenmodellierung ausgedrückt. Sessions bleiben durchgehend widerrufbar: Welche Ceremony auch immer zum Einsatz kommt – das Credential, das sie ausstellt, lässt sich in dem Moment beenden, in dem etwas verdächtig aussieht.