Passwortlose Anmeldung mit Magic Links: UX‑ und Sicherheitscheckliste

Was eine Magic‑Link-Anmeldung ist und was schiefgehen kann

Ein Magic Link ist ein einmaliger Anmeldelink, der an deine E‑Mail geschickt wird. Statt ein Passwort einzugeben, öffnest du die E‑Mail, tippst den Link an und bist angemeldet.

Das passt gut, wenn Menschen Passwörter hassen, sie oft vergessen oder nur selten anmelden müssen. Es reduziert zudem Passwort‑Wiederverwendung über Seiten hinweg, weil es gar kein Passwort mehr zum Wiederverwenden gibt. Es ersetzt jedoch nicht die Notwendigkeit für Sicherheit. Der Haupt‑„Schlüssel“ verlagert sich einfach in dein E‑Mail‑Postfach.

Das ist der Trade‑off: passwortlose Anmeldung mit Magic Links ist nur so sicher wie das E‑Mail‑Konto des Nutzers und dessen Fähigkeit, den Zugang privat zu halten. Wenn jemand deine E‑Mails lesen kann, kann er sich oft als du anmelden.

Hier sind die häufigsten Wege, wie Magic Links im echten Leben schiefgehen:

• Zugriff auf das Postfach wird gestohlen (Phishing des E‑Mail‑Passworts, SIM‑Swap für Passwort‑Recovery, Malware oder ein gemeinsam genutzter Computer, der eingeloggt blieb).
• Der Link wird weitergeleitet (absichtlich oder aus Versehen) und eine falsche Person nutzt ihn.
• Der Nutzer öffnet die E‑Mail auf einem Gerät, möchte die Sitzung aber auf einem anderen, und ist verwirrt, wenn die App am „falschen“ Ort öffnet.
• Ein gemeinsames Gerät bleibt angemeldet, sodass die nächste Person Zugriff hat.
• Die E‑Mail‑Adresse wurde falsch getippt und ein Login‑Link geht an jemand anderen.

Ein kleines Beispiel: Jemand fordert einen Link auf einem Arbeits‑Laptop an und checkt die E‑Mails dann auf dem privaten Handy. Er tippt den Link an, das Handy meldet ihn an, und der Laptop zeigt weiterhin den Anmeldebildschirm. Wenn dein Flow nicht erklärt, was passiert ist, folgen Support‑Tickets.

Wenn du das in einem Produkt baust, das mit AppMaster erstellt wurde, behandle den E‑Mail‑Schritt wie eine sensible Aktion, nicht nur als Komfortfunktion. Klare Kommunikation, kurzlebige Links und einfache Sitzungs‑Kontrollen machen das Erlebnis sicher.

Ist passwortlose E‑Mail‑Anmeldung das Richtige für dein Produkt?

Passwortlose Anmeldung mit Magic Links funktioniert am besten, wenn das Ziel schneller Zugang bei minimaler Friktion ist, nicht maximaler Schutz. Sie eignet sich für Produkte, bei denen Nutzer sich nur gelegentlich anmelden und Passwörter hassen, und wo das E‑Mail‑Postfach bereits das „Zuhause“ des Nutzers ist.

Eine einfache Entscheidungshilfe: Wenn jemand unerlaubt in ein Konto kommt, welcher reale Schaden ist am schlimmsten? Wenn die Antwort „ärgerlich, aber behebbar“ lautet, können Magic Links eine gute Default‑Lösung sein.

Gute Einsatzfälle sind oft:

• Apps mit geringem bis mittlerem Risiko (interne Tools, Admin‑Panels für kleine Teams, Kundenportale mit eingeschränkten Rechten)
• Produkte mit seltenen Nutzern, die Passwort‑Resets hassen
• „Bring mich schnell rein“-Erlebnisse wie Support, Onboarding oder Freigaben
• Frühphasen‑Produkte, die weniger Support‑Tickets brauchen

Sei vorsichtig oder vermeide Magic Links als einzige Anmeldemethode, wenn:

• Konten hohen Wert haben (Geldbewegungen, große Guthaben, irreversible Aktionen)
• Du regulierte oder sensible Daten speicherst (Gesundheit, Recht, detaillierte Finanzdaten)
• Nutzer üblicherweise E‑Mail‑Postfächer teilen (gemeinsame Postfächer, Rezeptionen)
• Deine Zielgruppe wahrscheinlich ins Visier genommen wird (Executives, Admins, privilegierte Rollen)

Wenn dein Produkt eher sensible Momente als sensible Konten hat, nutze E‑Mail‑Anmeldung für den Einstieg und füge für riskante Aktionen eine zweite Faktor‑ oder Step‑Up‑Prüfung hinzu. Beispielsweise eine zusätzliche Bestätigung beim Ändern von Auszahlungsdetails, beim Exportieren von Daten oder beim Hinzufügen eines neuen Admins.

Entscheide auch, was die E‑Mail tun darf. „Nur Anmeldung“-Magic‑Links sind sicherer und einfacher zu begründen. „Anmelden + Kontowiederherstellung“ ist bequem, bedeutet aber, dass jeder mit E‑Mail‑Zugriff das Konto übernehmen kann. Wenn du das Ändern der E‑Mail unterstützt, behandle das als hochriskante Aktion.

Wenn du eine App in einer No‑Code‑Plattform wie AppMaster baust, bleibt diese Entscheidung wichtig: die UI kann einfach sein, aber deine Richtlinie zu sensiblen Aktionen und Wiederherstellung sollte von Tag eins klar sein.

Der grundlegende Magic‑Link‑Flow (und die Entscheidungen darin)

Magic Links wirken für Nutzer simpel, doch unter der Haube sitzen viele kleine Entscheidungen. Ein klarer Flow hält Menschen in Bewegung und reduziert Support‑Tickets.

Der Flow, den Nutzer sehen

Die meisten Produkte folgen dem gleichen Pfad: Der Nutzer gibt eine E‑Mail ein, erhält eine Nachricht, tippt den Link an und landet angemeldet.

Eine häufige Verbesserung ist ein abschließender Bestätigungsbildschirm, nachdem der Link geöffnet wird. Statt sofort einzuloggen, zeigst du einen kurzen Screen wie „Anmeldung bei Acme bestätigen“ mit einer einzigen Taste. Das hilft, wenn jemand den Link auf dem falschen Gerät antippt oder die E‑Mail von einem Vorschau‑Tool geöffnet wurde.

Auf Mobilgeräten entscheide, was „Link antippen“ bedeutet. Wenn du eine native App hast, ist die beste Erfahrung meist: Link antippen -> App öffnen -> Anmeldung abschließen. Ist die App nicht installiert, fällt der Flow auf mobil Web zurück und bietet später eine Option „App öffnen“ an.

Entscheidungen, die du treffen musst

Bevor du passwortlose Anmeldung mit Magic Links baust, lege diese Regeln fest, damit das Erlebnis vorhersehbar ist:

• Wo der Link öffnet: In‑App‑Browser, Systembrowser oder direkt in der nativen App (Deep Link).
• Ob die Anmeldung automatisch erfolgt oder ein finaler Bestätigungsbildschirm nötig ist.
• Was passiert, wenn der Nutzer bereits angemeldet ist, wenn er den Link antippt.
• Was geschieht, wenn die E‑Mail während des Flows geändert wird oder der Nutzer beim nächsten Versuch eine andere E‑Mail eingibt.
• Wie „Erfolg“ aussieht: Auf der zuletzt besuchten Seite landen, auf einem Standard‑Homebildschirm oder auf der Seite, die die Anmeldung ausgelöst hat.

„Bereits angemeldet“ ist leicht zu übersehen. Wenn ein eingeloggter Nutzer einen neuen Magic Link antippt, kannst du (a) ihn im selben Konto lassen und „Du bist bereits angemeldet“ zeigen oder (b) es als Kontowechsel behandeln und um Bestätigung bitten. Für Apps, die in AppMaster gebaut werden (z. B. Kundenportale oder interne Tools), ist Option (a) meist sicherer, außer Kontowechsel ist tatsächlich eine Funktion.

Ablaufregeln: kurz genug, um sicher zu sein, lang genug, um zu funktionieren

Ein Magic Link ist nur dann „passwortlos“, wenn er mühelos wirkt. Die Ablaufzeit ist der Teil, der dieses Versprechen still kaputt machen kann. Zu kurz und Leute bekommen abgelaufene Links, zu lang und ein weitergeleiteter oder exponierter Link wird riskanter.

Ein praktischer Ausgangspunkt für passwortlose Anmeldung mit Magic Links ist ein Ablauffenster zwischen 10 und 30 Minuten. Kürzere Fenster (3–10 Minuten) passen zu höher riskanten Aktionen wie Admin‑Logins oder Zahlungsfreigaben. Längere Fenster (30–60 Minuten) können für Low‑Risk‑Apps funktionieren, aber nur wenn du starke Sitzungs‑Kontrollen und gutes Gerätemanagement hast.

Mache die Ablaufzeit in der E‑Mail und auf dem „Prüfe deine E‑Mail“-Bildschirm deutlich sichtbar. Verstecke sie nicht in kleingedrucktem Text. Nutze einfache Formulierungen wie „Dieser Link verfällt in 15 Minuten.“ Wenn möglich, zeige auf dem Warteschirm einen Countdown, verlasse dich aber nicht auf die Uhr des Geräts für Genauigkeit.

E‑Mail‑Verzögerungen und Uhrzeit‑Differenzen kommen häufig vor. Einige Provider halten Nachrichten ein paar Minuten zurück, und manche Nutzer öffnen die E‑Mail auf einem anderen Gerät als dem, das die Anfrage gestellt hat. Einige Regeln helfen, Verwirrung zu vermeiden:

• Behandle die Ablaufzeit anhand deiner Server‑Zeit, nicht der Zeit des Nutzers.
• Wenn ein Link kurz vor Ablauf steht, zeige eine klare Meldung wie „Link abgelaufen. Fordere einen neuen an.“
• Wenn der Link noch gültig, aber bereits benutzt wurde, sage das direkt (und biete einen schnellen nächsten Schritt an).

Bei abgelaufenen Links ist die beste Erfahrung ein Ein‑Tap‑Resend von der Landing‑Page. Halte es sicher: Erlaube einen erneuten Versand nur nach einer kurzen Abkühlzeit und vermeide, darüber auszusagen, ob eine E‑Mail bei dir registriert ist. Die Seite kann etwa sagen: „Wenn diese E‑Mail registriert ist, senden wir einen neuen Link.“

Ein kleines Detail, das Support‑Tickets reduziert: Zeige die genaue E‑Mail‑Adresse, an die der Link gesendet wurde (teilweise maskiert) auf dem Warteschirm, plus eine Option „E‑Mail ändern“. Wenn du den Flow in einem No‑Code‑Tool wie AppMaster baust, sind das meist nur ein paar UI‑Zustände, aber sie verhindern viel Verwirrung vom Typ „Ich habe die E‑Mail nie erhalten“.

Einmalige Nutzung und Wiederverwendungsregeln (die Teile, die Nutzer wirklich treffen)

Für die meisten Produkte ist die Standardeinstellung: Magic Links sind einmalig verwendbar. Das schützt Nutzer vor typischen Unfällen wie E‑Mail‑Weiterleitungen, geteilten Postfächern oder dem erneuten Öffnen einer alten Nachricht Wochen später. Es macht Support zudem einfacher: War ein Link genutzt, ist er fertig.

Der Schlüssel ist zu entscheiden, was „benutzt“ im echten Leben bedeutet. Menschen klicken zweimal, öffnen auf dem falschen Gerät oder tippen auf einen Link in der E‑Mail‑Vorschau. Deine Regeln sollten sicher, aber auch fair erscheinen.

Was sollte passieren, wenn derselbe Link zweimal geöffnet wird?

Eine gute Basisregel: Der erste erfolgreiche Login konsumiert das Token, und jedes spätere Öffnen zeigt eine klare Meldung wie „Dieser Link wurde bereits verwendet. Fordere einen neuen an.“ Vermeide vage Fehlermeldungen. Wenn du Frustration reduzieren willst, kannst du ein kleines Sicherheitsfenster vor der Konsumierung anbieten, z. B.: Markiere ihn erst nach Erstellung der Sitzung als benutzt.

Hier sind nutzerfreundliche Muster, die sicher bleiben:

• Wenn der Link erneut auf demselben Gerät geöffnet wird und der Nutzer bereits angemeldet ist, leite ihn in die App weiter (ohne Meldung).
• Wenn der Link erneut geöffnet wird, aber keine aktive Sitzung existiert, zeige „Verwendet oder abgelaufen“ plus eine Schaltfläche, um einen neuen Link zu senden.
• Wenn der Link auf einem anderen Gerät geöffnet wird, nachdem er bereits verwendet wurde, behandle ihn als ungültig und fordere einen neuen an.

Wenn Nutzer mehrere Links anfordern, verfallen ältere dann?

Entscheide das im Vorfeld und bleibe konsistent. Die sicherste Standardregel ist: Jede neue Anfrage macht alle vorherigen ausstehenden Links ungültig. Das begrenzt Schaden, falls jemand später Zugriff auf das Postfach erhält.

Wenn du mehrere Links gleichzeitig gültig lässt, brauchst du stärkere Schutzmaßnahmen (kurze Ablaufzeiten, strikte Einmalnutzung und klare Geräte-/Sitzungskontrollen). Ansonsten können Magic Links stillschweigend zu langlebigen Zugangsschlüsseln in E‑Mails werden.

Vermeide wiederverwendbare Links, die immer wieder funktionieren. Auch wenn das bequem erscheint, konditioniert es Nutzer, E‑Mail als permanenter Schlüssel zu behandeln, und macht Account‑Übernahmen schwerer einzudämmen.

Wenn du deinen Auth‑Flow in einem No‑Code‑Tool wie AppMaster baust, schreibe diese Regeln als einfache Zustände (gültig, benutzt, abgelaufen, ersetzt), damit deine UI‑Meldungen mit dem Backend‑Verhalten übereinstimmen.

UX‑Details, die Verwirrung und Support‑Tickets reduzieren

Die meisten Support‑Tickets rund um Magic Links sind keine Sicherheitsfehler. Sie sind „Ich habe die E‑Mail nicht bekommen“, „Ich habe geklickt und nichts ist passiert“ oder „Ist das Phishing?“. Gute UX verhindert alle drei.

Nachdem der Nutzer seine E‑Mail abgeschickt hat, zeige einen dedizierten „Prüfe deine E‑Mail“-Bildschirm statt eines kleinen Toasts. Mach ihn ruhig und spezifisch: Sag, an welche Adresse du gesendet hast, was als Nächstes zu tun ist und was zu probieren ist, falls nichts ankommt.

Ein starker Check‑E‑Mail‑Bildschirm enthält meist:

• Die exakte verwendete E‑Mail‑Adresse mit einer klaren Option „E‑Mail ändern“
• Eine Sende‑Wiederholen‑Taste mit kurzem Countdown (damit Nutzer nicht wild klicken)
• Einen Hinweis zur typischen Zustelldauer (z. B. „Kommt meist innerhalb 1 Minute an“)
• Einen freundlichen Hinweis, Spam‑ oder Promotions‑Ordner und Firmenfilter zu prüfen
• Eine kurze Sicherheitsnotiz: „Leite diesen Link nicht weiter"

Vertrauen gewinnt man in der E‑Mail selbst. Nutze einen konsistenten Absendernamen und Betreff und halte den Inhalt vorhersehbar. Füge ein oder zwei Details hinzu, die Nutzern Sicherheit geben, z. B. „Angefordert aus Chrome unter Windows“ oder „Angefordert um 15:42“. Vermeide alarmierende Formulierungen. Einfach ist besser: „Dieser Link meldet dich an. Wenn du ihn nicht angefordert hast, kannst du die E‑Mail ignorieren.“

Plane außerdem für das häufigste Problem: verzögerte oder gefilterte E‑Mails. Deine UI sollte nicht in eine Sackgasse führen. Wenn ein Link länger brauchen könnte, sag den Nutzern, was sie tun können, und biete eine freundliche Alternative.

Eine praktische Alternative ist, einen kurzen Einmal‑Code in derselben E‑Mail wie den Link aufzunehmen. Dann kann der Check‑E‑Mail‑Bildschirm „Code statt Link eingeben“ anbieten für Fälle, in denen der Link auf dem falschen Gerät geöffnet wurde oder von einem E‑Mail‑Scanner blockiert wird.

Ein kleines, aber wichtiges Detail: Wenn ein Nutzer einen alten oder bereits benutzten Link anklickt, zeige eine hilfreiche Meldung und eine einzelne klare Aktion wie „Schicke mir einen neuen Link“, nicht eine generische Fehlermeldung.

Sicherheitsgrundlagen hinter den Kulissen (ohne schwere Kryptotalks)

Ein Magic Link ist nur so sicher wie das Token dahinter. Behandle dieses Token wie einen temporären Schlüssel zum Konto: es muss schwer zu erraten, kurzlebig und nur auf die beabsichtigte Weise nutzbar sein.

Beginne mit Unvorhersehbarkeit. Erzeuge lange, zufällige Tokens (nicht basierend auf E‑Mail, Zeit oder inkrementellen IDs). Speichere so wenig wie möglich. Ein gängiges Muster ist, eine gehashte Version des Tokens zu speichern (so kann ein Datenbankleck den rohen Link nicht wiederverwenden) plus gerade genug Metadaten zur Validierung.

Das Binden des Tokens an Kontext kann Weiterleitung verhindern. Du willst nicht immer strikte Bindung (Nutzer wechseln Geräte), aber leichte Prüfungen fangen offensichtlichen Missbrauch ab. Beispiele: verknüpfe das Token mit der angeforderten E‑Mailadresse und optional mit einem groben Fingerabdruck wie der Browser‑Familie oder dem ersten IP‑Bereich. Passt der Kontext nicht, kannst du nach einem neuen Link fragen statt hart zu blocken.

Ratenbegrenzung ist wichtiger als ausgeklügelte Mathematik. Ohne sie können Angreifer dein Login‑Formular zuspammen, Nutzer belästigen und prüfen, ob E‑Mails existieren.

• Begrenze Anfragen pro E‑Mail und pro IP (inklusive Resends)
• Füge eine kurze Abkühlzeit zwischen E‑Mails hinzu (z. B. 30–60 Sekunden)
• Zeige dieselbe Meldung, egal ob die E‑Mail existiert oder nicht
• Alarmiere bei Spitzen (viele E‑Mails an viele Adressen)

Logge schließlich, was du wirklich brauchst, wenn ein Nutzer sagt „Das war ich nicht.“ Erfasse Ereignisse wie Link angefordert, E‑Mail gesendet, Link geöffnet, Token akzeptiert/fehlgeschlagen (und warum) und Sitzung erstellt. Inkludiere Zeitstempel, IP und User‑Agent. In einem Tool, das mit AppMaster gebaut wurde, können diese Ereignisse als Teil deines Login‑Business‑Prozesses gespeichert werden, sodass Support und Security eine klare Spur haben, ohne in Server‑Interna graben zu müssen.

Gerä­te‑ und Sitzungsmanagement, das Nutzer verstehen

Magic Links entfernen Passwörter, aber Nutzer denken weiterhin in Geräten: „Ich habe mich auf meinem Handy eingeloggt“ oder „Ich habe einen gemeinsamen Laptop genutzt.“ Wenn du ihnen keinen einfachen Weg gibst, Sitzungen zu sehen und zu beenden, steigen Support‑Anfragen schnell an.

Beginne mit einer Entscheidung: Wie viele aktive Sitzungen darf ein Konto gleichzeitig haben? Für die meisten Consumer‑Produkte sind mehrere Sitzungen in Ordnung (Handy + Laptop). Für sensitive Tools (Admin‑Panels, Finanzen, interne Operationen) kannst du es begrenzen oder beim Erscheinen eines neuen Geräts einen frischen Magic Link verlangen.

Eine kleine „Geräte“‑ oder „Aktive Sitzungen“‑Seite macht das leicht verständlich. Halte sie schlicht und etwas ungenau statt überpräzise. Eine gute Zeile enthält meist:

• Gerätename (oder Browser und OS, wenn das Modell nicht erkannt wird)
• Grobe Region (Stadt oder Region, nicht die genaue Adresse)
• Letzte Aktivität
• Erste Sichtung
• Ein kurzes Label wie „Dieses Gerät“ für die aktuelle Sitzung

Dort biete zwei klare Aktionen. „Abmelden“ beendet nur diese Sitzung. „Auf allen Geräten abmelden“ beendet alles, inklusive des aktuellen Geräts, und erzwingt neue Magic Links überall.

Zwischen diesen Aktionen definiere, was passiert, wenn ein Gerät verloren geht oder geteilt wurde. Die sicherste Standardvorgabe: Abmelden invalidiert alle bestehenden Sitzungen und alle ungenutzten Magic Links, die bereits versendet wurden. Nutzer brauchen die Details nicht; sie brauchen die Garantie, dass der alte Zugriff weg ist.

Hier ein einfaches Verhaltensset, das Nutzer selten überrascht:

• Neue Magic‑Link‑Anmeldung erstellt eine neue Sitzung
• Jede Sitzung hat ein Idle‑Timeout (z. B. Tage) und ein hartes Maximalalter (z. B. Wochen)
• E‑Mail‑Änderung löst „Abmelden von allen Geräten“ aus
• „Abmelden von allen Geräten“ annulliert auch ausstehende Sign‑In‑Links

Wenn du das in AppMaster baust, kannst du Sitzungen im Data Designer modellieren, sie in einer grundlegenden Web/Mobile‑UI anzeigen und Ein‑Knopf‑Aktionen in einem Business‑Process hinzufügen. Nutzer erhalten so eine vertraute „aktive Sitzungen“‑Ansicht, ohne dass du das zu einem Sicherheitstextbuch machen musst.

Bedrohungen und Randfälle: Weiterleitung, geteilte E‑Mails und Tippfehler

Magic Links wirken simpel, aber E‑Mail ist unordentlich. Leute leiten Nachrichten weiter, teilen Postfächer und tippen Adressen falsch. Wenn du nur für den perfekten Fall designst, endest du mit verwirrenden Sperren und schwer handhabbaren Support‑Anfragen.

Weiterleitung ist die größte Überraschung. Eine passwortlose Anmeldung mit Magic Links sollte annehmen, dass der Link von jemand anderem, auf einem anderen Gerät, Minuten oder Stunden später geöffnet werden könnte. Die sicherste Basis ist Einmalnutzung plus eine klare Meldung „Dieser Link wurde bereits verwendet“ mit einem frischen Anfrageknopf. Wenn du zusätzlichen Schutz willst, zeige nach dem Klick bei neuem Gerät einen leichten Bestätigungsbildschirm (z. B. „Warst du das?“ plus eine schnelle Abbruchoption, die die Sitzung widerruft).

Geteilte Postfächer brauchen eine Produktentscheidung, keinen technischen Patch. Wenn mehrere Personen legitimerweise dasselbe Postfach lesen (z. B. support@), werden Magic Links standardmäßig zu gemeinsamem Zugang. Erwäge, für „Team“-Konten einen zusätzlichen Schritt zu verlangen (z. B. Einladung an eine persönliche E‑Mail) oder mache in der UI deutlich, dass E‑Mail‑Zugriff Kontozugriff bedeutet.

Tippfehler erzeugen „Geisterkonten“ und unangenehme Datenschutzfragen. Vermeide es, beim ersten Login stillschweigend neue Konten zu erstellen, es sei denn, dein Produkt braucht das wirklich. Ein sichererer Ansatz ist, die Absicht in der App zu bestätigen, bevor du Onboarding betreibst, und die E‑Mail‑Antwort neutral zu halten (gleiche Meldung, egal ob Konto existiert oder nicht).

Aliases spielen ebenfalls eine Rolle. Entscheide, wie du Plus‑Addressing (name+tag@) und Provider‑Aliases behandelst:

• E‑Mails als exakte Strings behandeln (einfacher, weniger Überraschungen)
• Oder gängige Muster normalisieren (weniger doppelte Konten, aber Risiko, Nutzer zusammenzuführen, die das nicht erwarten)

Support ist der Ort, an dem Dinge schnell schiefgehen. Bitte Nutzer nicht, E‑Mails weiterzuleiten, Tokens einzufügen oder Screenshots von Links zu teilen. Biete stattdessen einfache In‑App‑Aktionen wie „Neuen Link senden“, „Andere Geräte abmelden“ und „Das war nicht ich melden“, damit Support helfen kann, ohne sensible Daten zu berühren.

Kurze Checkliste vor dem Start

Bevor du passwortlose Anmeldung mit Magic Links ausrollst, entscheide, wie du in der unordentlichen echten Welt mit langsamer E‑Mail‑Zustellung, doppeltem Antippen von Links und Gerätewechseln umgehen willst.

Beginne mit Regeln, die Risiko und Support‑Aufwand steuern. Wenn diese falsch sind, kann die UI das nicht retten.

• Setze ein klares Ablauffenster (oft 10–20 Minuten) und zeige es in der E‑Mail und auf dem „Prüfe deine E‑Mail“-Bildschirm.
• Mache Links standardmäßig einmalig nutzbar und definiere, was „benutzt“ bedeutet (nach Klick, nach erfolgreicher Sitzungserstellung oder nach erstem Öffnen).
• Füge Wiederhollimits und Pacing hinzu (z. B. kurze Abkühlzeit) sowie eine freundliche Meldung, warum man nicht immer wieder versenden kann.
• Begrenze aktive Sitzungen pro Nutzer, wo es Sinn macht, und entscheide, was passiert, wenn das Limit erreicht ist (neueste behalten, älteste behalten oder nachfragen).
• Handle mehrere Taps und alte Links vorhersehbar: Ist ein Link abgelaufen oder bereits verwendet, zeige eine einfache Seite mit einer primären Aktion („Sende einen neuen Link“).

Als Nächstes prüfe die Teile, die Nutzer tatsächlich sehen. Die meisten Beschwerden entstehen durch unklare E‑Mails und verwirrendes Mobilverhalten.

• E‑Mail‑Inhalt: Wiedererkennbarer Absendername, klarer Betreff, einfache Sprache und eine kurze Zeile „Nicht angefordert?“, die erklärt, was zu tun ist.
• Mobilverhalten: Bestätige, was passiert, wenn der Nutzer die E‑Mail auf einem Gerät öffnet, aber auf einem anderen Gerät angemeldet werden möchte, und ob Deep Links in deiner App unterstützt werden.
• Mehrfache Klicks: Wenn ein Nutzer zweimal tippt, vermeide beängstigende Fehler; sage, dass er bereits angemeldet ist oder dass der Link nicht mehr gültig ist.
• Gerätemanagement: Biete eine einfache Geräteliste, eine „Dieses Gerät abmelden“-Option und grundlegende Audit‑Infos (Zeit, Gerät, Ort, falls verfügbar).
• Wiederherstellung: Habe einen Plan für „Ich komme nicht an meine E‑Mail ran“ (Support‑Flow, alternative Verifizierung oder ein sicherer Prozess für Kontowechsel).

Wenn du das in einem Tool wie AppMaster baust, ordne jedes Checkliste‑Item einem konkreten Bildschirm und einer Business‑Regel in deiner Logik zu, damit das Verhalten über Web und Mobile hinweg konsistent bleibt.

Ein realistisches Beispiel: Anmeldung auf neuem Gerät, abgelaufener Link und Bereinigung

Maya arbeitet im Support. Am Montagmorgen öffnet sie das Kundenportal auf einem neuen Laptop. Sie gibt ihre Arbeits‑E‑Mail ein und tippt „Sende mir einen Anmeldelink“. Die E‑Mail kommt mit einem Magic Link, der in 10 Minuten verfällt.

Sie klickt ihn an, der Browser öffnet sich und sie landet im Portal. Im Hintergrund wird der Link einmal akzeptiert und dann als benutzt markiert. Das Portal erstellt eine neue Sitzung „Maya – Laptop Chrome“ und hält sie für 14 Tage angemeldet, sofern sie sich nicht abmeldet.

Später am Tag versucht Maya, sich von ihrem Handy aus anzumelden. Sie verwendet die alte E‑Mail aus dem Morgen und tippt denselben Link erneut an. Die App zeigt eine klare Meldung: „Dieser Link wurde bereits verwendet. Fordere einen neuen an.“ Sie fordert einen neuen Link an, wird aber abgelenkt. Fünfzehn Minuten später tippt sie ihn an und sieht: „Dieser Link ist abgelaufen. Fordere einen neuen an.“ Sie fordert erneut an, tippt sofort und die Handy‑Sitzung wird als „Maya – iPhone Safari“ erstellt.

Am Freitag hilft Maya einer Kollegin an einem gemeinsamen Büro‑Laptop. Sie meldet sich an, beendet die Aufgabe und geht dann zu „Geräte“, um „Von diesem Gerät abmelden“ zu wählen. Bevor sie geht, entfernt sie auch die Sitzung des geteilten Laptops aus ihrem Konto, damit dieser nicht mehr verwendet werden kann.

Hier sind die einfachen Regeln, denen die App folgte:

• Links verfallen schnell (Minuten), Sitzungen können aber länger dauern (Tage)
• Jeder Link funktioniert einmal; benutzte oder abgelaufene Links sind nicht wiederverwendbar
• Jede Anmeldung erzeugt eine benannte Gerätesitzung, die der Nutzer prüfen kann
• Nutzer können ein Gerät abmelden oder alle Sitzungen widerrufen, wenn nötig

Um diesen Flow in AppMaster zu bauen, starte mit dem Authentifizierungsmodul und aktiviere E‑Mail‑Sign‑In. Speichere Sitzungen in deiner Datenbank (Nutzer, Gerätename, Erstellungszeit, letzte Nutzung). Nutze das E‑Mail‑Messaging‑Modul, um die Anmelde‑E‑Mail zu senden, und einen kurzen Business‑Process, um den Token‑Zustand (ungueltig, benutzt, abgelaufen) zu prüfen, dann Sitzungen zu erstellen oder zu widerrufen. Wenn du passwortlose Anmeldung mit Magic Links ohne schweren Custom‑Code willst, kannst du die Bildschirme und Logik in den visuellen Editoren anlegen und es sofort testen.