was ist das hier
Ein zentraler Login-Punkt für alle meine privaten Tools. Ich melde mich einmal am "Tor" an, und von dort aus werden die Ziel-Apps — Terminal, Gym-Tracker, was auch kommt — ohne erneuten Zirkus aufgeschlossen. Eine UX, eine Session-Logik, ein mentales Modell.
Warum ein Tor statt vieler Türen
Sobald man mehr als zwei private Apps betreibt, passiert das Gleiche: jede App baut ihren eigenen Login. Die eine will Magic Link, die andere Passwort, die dritte hat eine alte Social-Auth liegen. Als Nutzer weiß ich nie, was mich gleich erwartet.
Verschiedene Login-Seiten für dasselbe "Ich" sind kein Feature. Es sind drei leicht falsche Gedächtnisabfragen pro Woche.
Und es ist nicht nur eine UX-Frage. Drei Login-Systeme bedeuten drei Cookie-Zonen, drei Sessions, drei Abmelde-Wege, drei Orte, an denen etwas schief gehen kann. Ein gemeinsames Tor reduziert all das auf eine Stelle.
Wie das Gate arbeitet
- 1
Einloggen am Tor
Ich gehe auf die zentrale Adresse
private.w3yh.xyzund melde mich dort an. Passwort-first, weil Passwortmanager das zuverlässig lösen. Magic Link nur als Fallback, wenn das Passwort verloren geht. - 2
Handoff ins Zielsystem
Nach erfolgreicher Anmeldung reicht das Tor einen kurzen, signierten Nachweis an das gewünschte Zielsystem weiter. Dieser Nachweis ist nur gültig, wenn er frisch, passend und unverändert ist.
- 3
App trägt meine Sitzung
Das Zielsystem legt die Sitzung in seiner eigenen Cookie-Zone an — streng auf die eigene Subdomain beschränkt. Keine Cookies, die über mehrere Apps schwappen.
Warum Passwort-first, nicht Magic Link first
Magic Link klingt modern und ist für einmalige Logins charmant. Für den Alltag ist er hakelig: jede Anmeldung verlangt einen Mail-Umweg, jede Session-Erneuerung potenziell auch. Passwort dagegen löst heute jeder Passwortmanager in einer Sekunde — inklusive Autofill.
Magic Link als Hauptweg
- Jede Anmeldung wartet auf die Mail.
- Abgelaufene Sessions sind jedes Mal ein Medienbruch.
- Passwortmanager haben nichts zu tun.
Passwort-first, Magic Link als Rettungsanker
- Autofill in einer Sekunde, im Alltag unsichtbar.
- Magic Link greift nur bei echtem Passwortverlust.
- Session-Logik ist an einer Stelle gepflegt.
Die Dissonanz, die noch sichtbar war
was ich übersehen hatte
Während der Hub schon auf "Passwort-first mit Gate-Handoff" eingeschwenkt war, stand auf einer der Subdomains noch der alte Satz: "Magic Link statt Passwort-Zirkus". Die Copy war noch bei einer früheren Designentscheidung, der Code war schon bei einer späteren. Für Besucher erzeugt das genau den Moment, an dem sie aufhören zu vertrauen: "Was soll ich jetzt glauben?"
Das ist kein Technikfehler — das ist ein Führungsfehler. Wenn mehrere private Apps auf ein gemeinsames Auth-Konzept umziehen, muss die Copy dieselben Begriffe benutzen. Sonst fühlt sich das Tor wie eine halbherzige Absprache an, nicht wie eine Entscheidung.
Ein gemeinsamer Login funktioniert nur, wenn er auch sprachlich einer ist.
Wie der Status gerade aussieht
- Hub, Terminal und Gym laufen bereits auf demselben Auth-Kurs.
- Die Passwort-first-UX ist im Code verdrahtet, nicht nur im Konzept.
- In-Hub-Passwort-Setzen und der Handoff sind gebaut, der Rücklauf-Pfad ("Auth-Callback") ist geschlossen.
- Offen ist nur noch der echte Live-Durchlauf auf realen Geräten — Passwort setzen, anmelden, abmelden, wieder anmelden, Session-Dauer prüfen.
Public Cut
Diese Seite zeigt die UX-Logik und die Designentscheidung dahinter. Sie zeigt keine Cookie-Namen, keine Signaturformate, keine Ziel-URLs im Handoff und keine internen Datenstrukturen. Das Prinzip ist öffentlich zitierfähig — die operativen Details sind es bewusst nicht.