Warum schlagen meine Magic-Link-Logins fehl?

Der Fehler, der wie ein Bedienfehler aussieht

Das Symptom ist immer dasselbe und immer verwirrend. Jemand fordert einen Login-Link an, der Link kommt an, die Person klickt, und deine Anwendung sagt, er sei ungültig oder bereits benutzt. In deinen Logs sieht nichts kaputt aus: Die Mail wurde angenommen, das Token wurde erzeugt, das Token wurde verifiziert. Verifiziert wurde es — nur nicht von der Person, der du es geschickt hast. Zwischen deinem Versand und ihrem Klick liest eine ganze Reihe von Maschinen diese Nachricht: das E-Mail-Sicherheitsprodukt der Empfängerseite, das Links umschreibt und zur Prüfung aufruft, der Mail-Client, der vorablädt, damit die Vorschau sofort erscheint, Unternehmens-Gateways, die URLs in einer Sandbox zünden, und manchmal ein Filter, der am Eingang dasselbe tut.

Uns ist das im August 2026 im eigenen produktiven Registrierungsablauf passiert, und die Form lohnt das Nacherzählen, weil sie nach nichts aussah. Eine Anmeldung forderte in einer Sitzung drei Links an. Alle drei wurden serverseitig 16 bis 23 Sekunden nach dem Versand verifiziert — viel zu schnell für jemanden, der ein Postfach liest — und jeder menschliche Klick danach wurde als bereits verwendet abgewiesen. Die Person kam erst hinein, indem sie noch einmal mit einem Social-Login von vorn begann. Zwei ganz gewöhnliche Gewohnheiten verschärfen das und erzeugen dieselbe Logzeile: Man fordert den Link auf dem Handy an und öffnet ihn am Laptop, und man leitet die Login-Mail an Kolleginnen oder an die eigene zweite Adresse weiter. Wenn dein Entwurf annimmt, die erste Anfrage nach einem Token komme aus dem Browser des Menschen, dann lesen sich alle drei Fälle wie ein Angriff, obwohl sie der Normalfall sind.

Herausfinden, welcher Fall deiner ist

Bevor du irgendetwas änderst, finde heraus, was das Token tatsächlich verbraucht hat. Der Zeitstempel verrät es: Ein Scanner oder ein Vorablader landet innerhalb von Sekunden nach dem Versand, ein Mensch braucht Dutzende Sekunden bis Minuten. Protokolliere Zeit, User-Agent und IP jeder Verifizierung neben der Versandzeit und lies beides zusammen.

Die Lösung, in der Reihenfolge, auf die es ankommt

Die Reihenfolge trägt das Ganze, denn zwei dieser Schritte sind für sich sicher und in der falschen Abfolge gefährlich.

1. Ablauf prüfen, bevor du verbrauchst Ein abgelaufenes Token darf niemals eine Sitzung öffnen, was immer du sonst änderst. Die Ablaufprüfung nach vorn zu ziehen ist das, was den nächsten Schritt sicher macht — ohne sie würde das Dulden eines wiederholten Öffnens die Lebensdauer des Links verlängern, statt bloß einen zusätzlichen Aufruf zu überstehen.
2. Einen nicht abgelaufenen Link mehrfach öffnen lassen Nimm ein Token an, das bereits verifiziert wurde, aber noch innerhalb seiner Lebensdauer liegt, und gib statt eines Fehlers ein Kennzeichen zurück, das genau das sagt. Ein Link soll sterben, wenn er abläuft, nicht wenn die erste Maschine ihn berührt.
3. Den ersten Verifizierungszeitpunkt behalten Wenn du ein wiederholtes Öffnen zulässt, überschreibe den ursprünglichen Verbrauchszeitpunkt nicht. Er ist der einzige Nachweis darüber, welcher Aufruf tatsächlich gewonnen hat, und das Erste, was du beim nächsten Bericht dieser Art sehen willst.
4. Das Fenster verkürzen, statt die Aufrufe zu verengen Ein kurzlebiger Link, der mehrere Aufrufe verträgt, ist in der Praxis sicherer als ein langlebiger, der bei der ersten Berührung stirbt. Die Sicherheitsarbeit leistet die kurze Lebensdauer; die Einmalnutzung war dafür immer nur ein Stellvertreter.
5. Immer eine zweite Tür offenlassen Biete einen anderen Weg hinein — ein Passwort, einen Passkey oder ein Social-Login — und zeige ihn auf der Fehlerseite selbst, nicht drei Klicks entfernt. Die Anmeldung, die uns das gekostet hätte, kam über ein Social-Login zurück; ohne diese Tür wäre sie an der Schwelle verloren gewesen.
6. Etwas Brauchbares sagen, wenn es doch scheitert "Ungültiger Link" teilt jemandem mit, er habe etwas falsch gemacht. "Dieser Link ist abgelaufen — hier ist ein neuer", mit einem Neuversand per Tipp auf derselben Seite, hält die Person im Ablauf, statt sie in dein Support-Postfach zu schicken.

Der Teil, der nie als Bug gemeldet wird

Der Login-Fehler ist sichtbar. Der Schaden an der Messung ist es nicht, und er überlebt den Bug. Wenn dein Conversion-Ereignis für Registrierungen bei der ersten Anfrage feuert, die deinen Verifizierungs-Endpunkt erreicht, dann reitet die Conversion jedes Mal, wenn ein Scanner zuerst dort ist, auf einer Weiterleitung, die kein Browser je ausführt. Genau das ist uns passiert: Die Markierung für eine brandneue Registrierung reiste mit der Anfrage des Scanners, und so wurde die Registrierungs-Conversion dieser Person in der Werbeplattform nie erfasst. Wer auf diese Daten bietet, bietet auf eine Zahl, der still und leise einige ihrer am härtesten erarbeiteten Conversions fehlen.

Die Gewohnheit, die das auffängt, ist unspektakulär, aber verlässlich: Zähle die abgeschlossene Sitzung, nicht den Klick auf den Link, und behandle den Abstand zwischen "Link angefordert" und "Sitzung erstellt" als eigene Trichterstufe. Wenn ein nennenswerter Anteil der Anforderungen nie zu einer Sitzung wird, hilft keine Arbeit an der Landingpage — das ist ein Mechanikfehler, kein Überzeugungsfehler. Die Stufe davor steht in wie du Website-Besucher zu Anmeldungen machst, die Stufe danach in Aktivierungsrate. Kommt die Mail überhaupt nicht an, gilt die Domain-Authentifizierungsleiter aus wie du Cold Mails schreibst, die nicht im Spam landen genauso für transaktionale Post. Und wenn du erst entscheidest, von wo aus du sie überhaupt versendest, ist Notifuse eine selbst gehostete Option.