Warum wir klassischen Passwort Login begraben haben

Login ist einer dieser Bereiche, über den niemand nachdenken will. E-Mail, Passwort, vielleicht noch ein zweiter Faktor, fertig.

In der Praxis ist genau das aber eine ständige Quelle für Supporttickets, Sicherheitsrisiken und Frust. Irgendwann standen wir vor der Frage: Wollen wir wirklich noch ein weiteres System bauen, das Passwörter speichert, zurücksetzt und überwacht?

Unsere Antwort war: nein.

In diesem Artikel erzähle ich dir, warum wir klassischen Passwort Login bewusst begraben haben, wie wir bei Magic Link und Stytch gelandet sind, welche Architekturentscheidungen dahinterstecken und was das für Sicherheit und UX bedeutet.

Ausgangspunkt: Der vermeintliche Standardweg

Am Anfang stand der Klassiker: Nutzer erstellt ein Konto, wählt ein Passwort, bekommt eine Bestätigungsmail und später gibt es einen Flow für Passwort vergessen, Passwort ändern und E-Mail verifizieren.

Jede dieser Stufen bringt eigene Baustellen mit: schwache Passwörter und Passwortrecycling, Hashing und Bruteforce-Schutz, nervige Reset Flows, E-Mails im Spam und Endpunkte, die niemand mehr pflegt. Wir hätten das alles selbst bauen können, hätten dann aber auch alle Risiken dauerhaft selbst tragen müssen.

Die Optionen auf dem Tisch

Option 1: Klassischer Passwort Login in Eigenregie

Der offensichtliche Vorteil: volle Kontrolle, keine externe Abhängigkeit. Die Nachteile überwiegen aber schnell: Wir tragen die komplette Sicherheitsverantwortung, müssen sichere Speicherung, Rate Limits, Reset Flows und E-Mail Zustellung selbst lösen und erhalten am Ende trotzdem nur eine mittelmäßige UX mit komplexen Passwortregeln und vergessenen Zugangsdaten.

Option 2: Social Login und OAuth only

Hier loggen sich Nutzer mit bestehenden Konten ein, etwa Google oder GitHub. Wir speichern keine Passwörter, was auf den ersten Blick attraktiv ist. In der Praxis möchte aber nicht jeder sein Konto koppeln, nicht jede Umgebung erlaubt alle Provider und wir würden uns stark an wenige Ökosysteme binden. Gut als Zusatz, aber nicht als einzige Säule.

Option 3: Magic Link mit spezialisiertem Provider

Magic Link verlagert das Problem: statt eines Passworts ist die E-Mail der zentrale Faktor. Ein spezialisierter Provider wie Stytch übernimmt viel Low-Level-Arbeit rund um Tokens, Links und Sicherheit. Die Abhängigkeit nach außen bleibt, aber wir bekommen die Chance, unser eigenes System schlanker und klarer zu halten.

Damit war ziemlich schnell klar: Wenn wir Login neu denken, dann in diese Richtung.

Entscheidung: Magic Link statt Passwort

Wir haben uns für Magic Link basierend auf Stytch entschieden. Die Kernidee: Nutzer gibt seine E-Mail ein, bekommt einen Magic Link, klickt ihn, landet bei uns, wird authentifiziert und bekommt eine Session. Kein Passwort, das wir speichern oder zurücksetzen müssen.

Damit verschieben wir viele der klassischen Passwortprobleme. Es gibt kein Passwort mehr, das in einem Leak auftauchen kann, keinen Reset-Flow, der ständig bricht, und weniger Angriffsfläche für Credential Stuffing mit wiederverwendeten Passwörtern. Gleichzeitig heißt das nicht, dass wir "Sicherheit ausgelagert" hätten – wir haben andere Stellen bewusst geschärft.

Architektur: Was passiert, wenn jemand sich einloggt?

1. Magic Link anfordern

Der Flow beginnt mit einem Request an unsere Auth API. Wir validieren den Input über Zod, setzen Rate Limits auf den Endpunkt und übergeben die notwendigen Daten an Stytch. Der Nutzer erhält eine E-Mail mit einem Link.

Schon hier achten wir auf Logging ohne PII und konsistente Fehlertypen, damit weder Angreifer noch echte Nutzer unnötige Informationen über existierende Konten erhalten.

2. Rückkehr über den Magic Link

Beim Klick auf den Link landet der Nutzer auf einem Callback-Endpunkt bei uns. Wir validieren die Antwort von Stytch und den Kontext der Anfrage, etwa Origin und CSRF. Wenn alles passt, legen wir eine Session an.

Die Session basiert auf einem HttpOnly Cookie mit strengen Einstellungen: Secure, ein klarer Geltungsbereich und so konfiguriert, dass es nicht quer durch alle möglichen Subdomains läuft. Im Cookie selbst steckt nur ein Identifier, der auf Serverseite aufgelöst wird.

3. Authentifizierte Requests

Geschützte API-Routen laufen über eine zentrale Auth-Middleware. Diese liest die Session, prüft gegebenenfalls Plan oder Rolle, setzt Security Header und erzwingt Origin-Regeln und CSRF-Schutz bei unsicheren Methoden. Die eigentliche Business-Logik bleibt damit von Auth-Details weitgehend entkoppelt.

Sicherheit: Was wir bewusst schärfer gemacht haben

Der Verzicht auf Passwörter ist kein Freifahrtschein. Wir haben mehrere Entscheidungen getroffen, die im Alltag kaum auffallen, für uns aber nicht verhandelbar sind:

Wir haben keine versteckten Fallback-Logins; wenn wir Magic Link sagen, meinen wir Magic Link. Session-Cookies sind strikt konfiguriert. Unsichere Methoden sind an Origin-Checks und bei sensiblen Routen an einen Double-Submit-CSRF-Schutz gekoppelt. Auth-Endpunkte sind rate-limited und unsere Logs sind so gestaltet, dass wir Probleme nachvollziehen können, ohne personenbezogene Daten zu verewigen.

UX: Warum das nicht nur ein Sicherheitsfeature ist

Sicherheit ohne eine brauchbare Nutzererfahrung bringt wenig. Magic Link hat für uns auch UX-Vorteile: kein Passwort merken, kein Passwort vergessen, kein Pflichtwechsel alle paar Monate. Der Flow bleibt klar: E-Mail eingeben, Link klicken, fertig.

Natürlich braucht das zuverlässige E-Mail Zustellung und ein UI, das erklärt, was passiert. Aber die mentale Last "Welches Passwort hatte ich hier noch mal?" fällt weg.

Learnings auf dem Weg

Ein paar Dinge haben wir aus dieser Umstellung mitgenommen: Wir haben Komplexität von "Passwortsystem bauen" in "Sessions, Middleware, Cookies, CSRF" verschoben. Das ist überschaubarer, aber immer noch ernst. Ein spezialisierter Provider nimmt uns Arbeit ab, aber keine Architekturentscheidungen. Und je weniger Auth-Pfade wir haben, desto einfacher wird Testen, Debuggen und Erklären.

Magic Link ist für uns ein Beispiel dafür, dass sich Sicherheit und UX nicht ausschließen müssen. In unserem Fall haben wir beides verbessert, indem wir die richtigen Baustellen angegangen sind.

Ausblick

Unser Login-System ist damit keine abgeschlossene Geschichte, sondern eine Basis. Darauf können wir weitere Faktoren ergänzen, besser mit Rollen, Plänen und Limits arbeiten und Auth-Flows in neue Oberflächen integrieren, ohne jedes Mal von vorne anzufangen.

In einem der nächsten Artikel gehe ich tiefer in die Middleware-Schicht und zeige, wie viel unsichtbare Arbeit dort passiert, damit sich Requests für dich ganz normal anfühlen.