Authentifizierungsmethoden, die 2026 funktionieren

6 Min. Lesezeit

Was beim Anmelden tatsächlich funktioniert

Das Passwort-Problem, das wir für gelöst halten

Die meisten Websites setzen noch immer auf Anmeldung per E-Mail und Passwort. Die meisten Nutzer verwenden dasselbe Passwort für Dutzende von Diensten. Die meisten Sicherheitsvorfälle nutzen genau das aus. Wir wissen das seit zwanzig Jahren und haben mit Komplexitätsregeln reagiert, die legitime Nutzer bestrafen, während Angreifer schlicht gestohlene Zugangsdaten in großen Mengen kaufen.

Die gute Nachricht: brauchbare Alternativen sind keine Theorie mehr. Sie werden in jedem gängigen Browser und Betriebssystem ausgeliefert. Die schlechte Nachricht: Die meisten Entwicklungsteams hinken hinterher.

Hier ein Überblick über das, was verfügbar ist und was sich lohnt.

Passkeys und WebAuthn

Passkeys sind die bedeutendste Verbesserung in der Web-Authentifizierung seit es Web-Authentifizierung gibt. Aufgebaut auf dem WebAuthn-Standard (mittlerweile Level 3) ersetzen sie Passwörter durch asymmetrische Kryptografie. Der private Schlüssel verlässt nie das Gerät des Nutzers. Der Server speichert nur den öffentlichen Schlüssel. Nichts, was sich aus der Datenbank stehlen ließe.

Apple, Google und Microsoft synchronisieren Passkeys über ihre jeweiligen Ökosysteme hinweg. Wer einen Passkey auf dem iPhone erstellt, kann ihn auf dem Mac, dem iPad und per geräteübergreifender Authentifizierung sogar auf einem Windows-Rechner verwenden. Android nutzt den Google Password Manager. Windows setzt auf Windows Hello.

Für Entwickler ist die WebAuthn-API unkompliziert. Man ruft navigator.credentials.create() für die Registrierung und navigator.credentials.get() für die Anmeldung auf. Bibliotheken wie SimpleWebAuthn (JavaScript), py_webauthn (Python) und webauthn-rs (Rust) übernehmen die kryptografische Prüfung auf dem Server. Der gesamte Ablauf besteht aus wenigen API-Aufrufen, nicht aus einer Doktorarbeit.

Die größte Herausforderung: Nutzer ohne Passkey-fähige Geräte oder solche, die zwischen Ökosystemen wechseln. Eine Ausweichoption wird noch eine Weile nötig sein.

Einstiegspunkt: Die Dokumentation auf passkeys.dev ist sehr gut. Die Entwicklerdokumentation von Apple und Google führt Schritt für Schritt durch die Implementierung. Als serverseitige Bibliothek im JavaScript-Ökosystem hat SimpleWebAuthn die beste Dokumentation.

OAuth 2.0 und OpenID Connect

OAuth 2.0 mit OpenID Connect (OIDC) bleibt der Standard für delegierte Authentifizierung. „Mit Google anmelden”, „Mit GitHub anmelden” und ähnliche Verfahren nutzen genau das. Die eigene Anwendung sieht das Passwort des Nutzers nie. Der Identitätsanbieter übernimmt die Authentifizierung und liefert ein Token.

OIDC fügt eine Identitätsschicht über das Autorisierungs-Framework von OAuth 2.0 hinzu. Man erhält ein ID-Token (ein signiertes JWT), das die Identität des Nutzers bestätigt, plus ein Access-Token für API-Aufrufe. Der Authorization Code Flow mit PKCE ist der empfohlene Ansatz für Webanwendungen. Der Implicit Flow ist veraltet. Nicht verwenden.

Für die meisten Webanwendungen deckt Social Login über OIDC einen erheblichen Teil der Nutzer ab. Google allein authentifiziert Milliarden Nutzer. GitHub eignet sich gut für entwicklerorientierte Produkte. Apple Sign In ist für iOS-Apps vorgeschrieben, die Login über Drittanbieter anbieten.

Der Nachteil: Man ist von externen Anbietern abhängig. Wenn der Authentifizierungsdienst von Google ausfällt, können sich die eigenen Nutzer nicht anmelden. Außerdem übernimmt man deren Datenschutzrichtlinien und eventuelle Änderungen an den Authentifizierungsanforderungen.

Einstiegspunkt: Auth0, Clerk und Supabase Auth bieten verwaltete OIDC-Abläufe, die einem die eigenständige Implementierung des Protokolls ersparen. Wer es selbst betreiben will: Keycloak und Authentik sind solide Open-Source-Lösungen.

Magic Links

Magic Links senden eine einmalige Anmelde-URL an die E-Mail-Adresse des Nutzers. Klick auf den Link, man ist angemeldet. Kein Passwort zum Merken, kein Passwort zum Stehlen. Slack hat dieses Muster vor Jahren populär gemacht.

Die Implementierung ist unkompliziert: einen kryptografisch zufälligen Token erzeugen, mit einer Gültigkeitsdauer (10 bis 15 Minuten) speichern, als Link per E-Mail versenden und beim Klick den Token prüfen und eine Sitzung erstellen. Den Token sofort nach Verwendung ungültig machen.

Die Nutzererfahrung ist gut für Anwendungen, die gelegentlich besucht werden. Bei täglicher Nutzung wird der ständige Umweg über das Postfach zur Reibung. Magic Links mit langlebigen Sitzungen und „Dieses Gerät merken”-Cookies kombinieren, um diese Unannehmlichkeit zu reduzieren.

Die Sicherheit hängt vollständig von der E-Mail-Sicherheit ab. Wer Zugriff auf das Postfach hat, kann sich einloggen. Das ist ein reales Risiko, aber kein größeres als Passwort-Zurücksetzungen, die jedes passwortbasierte System bereits hat.

Mehrstufige Authentifizierung

Mehrstufige Authentifizierung (MFA) sollte Standard sein, nicht Ausnahme. Man kombiniert etwas, das der Nutzer weiß (Passwort oder PIN), mit etwas, das er besitzt (Gerät), oder etwas, das er ist (Biometrie).

Optionen, grob nach Sicherheit sortiert:

1. Hardware-Sicherheitsschlüssel (YubiKey, Titan) mit FIDO2. Phishing-resistent. Nichts abzufangen.
2. Passkeys mit biometrischer Prüfung. Das Gerät ist der zweite Faktor. Touch ID, Face ID, Windows Hello.
3. TOTP-Apps (Google Authenticator, Authy, 1Password). Sechsstellige Codes, die alle 30 Sekunden wechseln. Gut verstanden, breit unterstützt.
4. Push-Benachrichtigungen über Authentifizierungs-Apps. Bequem, aber anfällig für MFA-Müdigkeitsangriffe (den Nutzer mit Aufforderungen überhäufen, bis er eine bestätigt).
5. SMS-Codes. Besser als nichts. Anfällig für SIM-Swapping und SS7-Angriffe. Als letzten Ausweg verwenden, nicht als erste Wahl.

Wenn die Anwendung mit Geld, Gesundheitsdaten oder irgendetwas umgeht, dessen Verlust Nutzer verärgern würde: MFA vorschreiben. Nicht nur anbieten. Vorschreiben.

Einstiegspunkt: Der TOTP-Standard ist in RFC 6238 definiert. Bibliotheken gibt es für jede Sprache. Für Hardware-Schlüssel nutzt man dieselbe WebAuthn-Infrastruktur, die auch Passkeys antreibt.

Sitzungsverwaltung: JWTs oder serverseitige Sitzungen

Nach der Authentifizierung muss der Nutzer angemeldet bleiben. Zwei Ansätze:

Serverseitige Sitzungen speichern Sitzungsdaten auf dem Server (im Arbeitsspeicher, Redis oder einer Datenbank). Der Client erhält eine anonyme Sitzungs-ID in einem Cookie. Einfach, widerrufbar, bewährt. Wenn ein Nutzer sich abmeldet oder eine Sitzung sofort beendet werden muss, löscht man sie aus dem Speicher. Fertig.

JWTs kodieren Sitzungsdaten in ein signiertes Token, das clientseitig gespeichert wird. Kein serverseitiger Zustand. Das Token ist eigenständig. Klingt elegant, bis man eines widerrufen muss. JWTs sind gültig, bis sie ablaufen. Wenn ein Nutzerkonto kompromittiert ist und die Sitzung sofort beendet werden muss, baut man am Ende eine Token-Sperrliste, was nichts anderes ist als eine serverseitige Sitzungsverwaltung mit zusätzlichen Schritten.

Für die meisten Webanwendungen: serverseitige Sitzungen verwenden. Sie sind einfacher, widerrufbar und erfordern nicht, Probleme zu lösen, die nur existieren, weil man JWTs gewählt hat. JWTs eignen sich für API-zu-API-Kommunikation, wo Zustandslosigkeit tatsächlich relevant ist.

API-Authentifizierung

Für Maschine-zu-Maschine-Kommunikation und API-Zugriff:

• API-Schlüssel für einfache Fälle. Leicht zu implementieren, leicht zu rotieren. Nicht über Query-Parameter senden. Den Authorization-Header verwenden.
• OAuth 2.0 Client Credentials für Dienst-zu-Dienst-Aufrufe mit abgestuften Berechtigungen.
• Gegenseitiges TLS (mTLS) für Hochsicherheitsumgebungen, in denen Client und Server Zertifikate vorlegen.

API-Schlüssel reichen für die meisten internen Dienste und Entwickler-APIs. Sie müssen nur nach Bereichen getrennt, rotierbar und nie in die Versionskontrolle eingecheckt sein. (Die eigene git-Historie jetzt prüfen. Man wird vermutlich einen finden.)

Was man lassen sollte

Einige Praktiken müssen verschwinden:

• Anmeldung nur mit Passwort, ohne MFA. Wir schreiben 2026. Aufhören.
• SMS als einziger zweiter Faktor. SIM-Swapping ist für motivierte Angreifer trivial.
• Eigene Kryptografie erfinden. Etablierte Bibliotheken verwenden. Jedes Mal, wenn jemand ein eigenes Token-Format baut, findet ein Sicherheitsforscher innerhalb weniger Wochen eine Umgehung.
• Passwörter in etwas anderem als bcrypt, scrypt oder Argon2 speichern. Wenn die Datenbank SHA-256-gehashte Passwörter enthält, gibt es ein Problem.
• Sicherheitsfragen. Der Mädchenname der Mutter steht auf Facebook. Der Name des ersten Haustiers auf Instagram. Das ist keine Sicherheit. Das ist Theater.

Den eigenen Authentifizierungs-Stack zusammenstellen

Für eine neue Webanwendung 2026 ein sinnvoller Standard:

1. Primär: Passkeys für Nutzer mit modernen Geräten.
2. Ausweichoption: Magic Links für Nutzer ohne Passkey-Unterstützung.
3. Firmenkunden: OIDC-Integration mit Unternehmens-Identitätsanbietern (Azure AD, Okta).
4. MFA: Verpflichtend, mittels TOTP oder Hardware-Schlüssel.
5. Sitzungen: Serverseitig, in Redis gespeichert, mit HTTP-only Secure Cookies.

Diese Kombination deckt die meisten Nutzer ab, widersteht Phishing und erfordert kein eigenes Passwort-Verwaltungssystem.

Authentifizierung ist nicht der spannendste Teil beim Aufbau eines Produkts. Aber es ist der Teil, der Schlagzeilen macht, wenn er versagt. Die Zeit investieren, es richtig zu machen. Die Werkzeuge sind besser als je zuvor.