Ein System die Identität besitzen lassen
Das Login-Formular sammelt eine Anfrage. Das Auth-System entscheidet, ob diese Anfrage eine Identität begründet, und stellt die Session aus, der der Rest der App vertraut. Diese Verantwortung an einem Ort zu halten verhindert, dass jede Route ihre eigene Interpretation eines angemeldeten Nutzers erfindet.
supastack integriert Better Auth für Identität und Session-Verwaltung. Anwendungscode löst die Session an geschützten Grenzen auf und verknüpft sie mit einem Workspace. Das UI kann nützliche Zugangszustände zeigen, aber Client-Zustand darf nie zum Beweis werden, dass eine Operation erlaubt ist.
Die Regel muss auf jeder Oberfläche gelten, die das Produkt ausliefert. Web-, Mobile- und Desktop-Clients sollten dieselbe Identitätsentscheidung konsumieren, statt sie dreimal zu implementieren — drei Interpretationen von „angemeldet“ sind der Ursprung von Konto-Bugs.
Anmeldemethoden bewusst wählen
Jede Methode tauscht Reibung gegen Angriffsfläche und eine externe Abhängigkeit. Passwörter brauchen Reset-Flows und Rate-Limiting. Magic Links und Einmalcodes hängen von der E-Mail-Zustellbarkeit ab. OAuth delegiert Identität an Anbieter wie Google, GitHub oder Apple — und erbt deren Ausfälle, Consent-Screens und Callback-Regeln.
supastack komponiert sie über Better Auth — E-Mail-OTP, Passwort, Magic Link, OAuth, mit Zwei-Faktor und Passkeys verfügbar — hinter einer einzigen Identitätsentscheidung. Liefere die kleinste Menge aus, die dein Publikum wirklich braucht; jede zusätzliche Methode ist ein weiterer Callback-Pfad, ein weiterer Fehlermodus und ein weiterer Ablauf, der vor dem Launch verifiziert werden muss. Der Authentifizierungs-Guide deckt die Verdrahtung ab.
Kann sich eine Person auf mehr als einem Weg anmelden, entscheide, wie die Methoden zusammenlaufen. Ein Google-Konto und ein E-Mail-Magic-Link, die auf dieselbe Adresse zeigen, sollten auf einer Identität landen, nicht auf zweien. Regeln zum Konten-Verknüpfen sind Teil der Identitätsentscheidung — wer sie falsch macht, erzeugt doppelte Nutzer, die Monate später als rätselhaft fehlende Daten auftauchen.
Sessions sind der Zugangsnachweis, auf den es ankommt
Nach der Anmeldung ist es die Session — nicht das Passwort —, die jede Anfrage trägt. Ihre Ablauf-, Speicher- und Ungültigkeitsregeln definieren die echte Sicherheitslage. Eine Session, die den Sign-out überlebt oder die ein entferntes Workspace-Mitglied weiterverwenden kann, ist ein Authentifizierungsfehler, den kein polierter Login-Screen repariert.
Entscheide den Lifecycle vorab: wie lange Sessions leben, ob Nutzer ihre aktiven Sessions sehen und widerrufen können und was eine Passwort- oder E-Mail-Änderung oder ein Workspace-Ausschluss mit ihnen macht. Session-Verwaltung existiert im Kit genau deshalb als Modul, weil sich diese Entscheidungen leicht aufschieben und teuer nachrüsten lassen.
Die Session mit dem angefragten Datensatz verknüpfen
Angemeldet zu sein gewährt keinen Zugang zu jedem Datensatz. Löse den Workspace des Nutzers serverseitig auf und nimm diese Grenze in Lese- und Schreiboperationen auf. Eine Task-ID oder ein Wiederherstellungs-Link ist eine Referenz auf Arbeit, keine Erlaubnis, sie abzurufen — der Workspace-Grenzen-Post behandelt diese Seite der Grenze im Detail.
Löse den Scope in fester Reihenfolge auf: authentifiziere die Session, lade die Mitgliedschaft, dann lies oder schreibe mit diesem Workspace-Kontext — niemals umgekehrt. Middleware kann einen anonymen Besucher umleiten, aber sie kann die Operation nicht autorisieren; die Prüfung gehört in die Server-Action oder den Route-Handler, wo der Datensatz berührt wird.
Konten haben einen Lifecycle, nicht nur einen Anfang
Das Provisioning ist der erste Test dieser Grenze. Meldet sich ein Nutzer an, müssen der Workspace und die folgenden Besitzdatensätze sicher mehr als einmal erstellbar sein — Lifecycle-Hooks können von Anbietern, Retries oder Support-Werkzeugen erneut abgespielt werden. Ein doppeltes Event sollte ein No-op sein, keine doppelte Organisation.
Das Ende des Lifecycles verdient dieselbe Sorgfalt. E-Mail-Änderungen, Passwort-Resets, Mitgliedsentfernung, Kontolöschung und Datenexport sind jeweils kleine Abläufe mit eigenen Missbrauchsfällen — ein Reset-Link, der zweimal funktioniert, ein Export, der die Datensätze eines Teammitglieds durchsickern lässt. supastack liefert aus diesem Grund GDPR-Export und Session-Verwaltung mit; worauf du auch baust, plane Budget für die langweiligen Abläufe ein.
Den Lifecycle testen — einschließlich seines Endes
Ein erfolgreicher Login-Test ist nützlich, aber unvollständig. Übe ungültige Zugangsdaten, abgelaufene oder wiederverwendete Verifizierungscodes, anonyme Anfragen und Workspace-übergreifenden Zugang. Verifiziere, dass Abmeldung die Session ungültig macht und dass ein wiederkehrender Client keinen zuvor autorisierten Screen für geschützte Arbeit weiterverwenden kann.
Unterscheide Handler-Tests von Deployment-Akzeptanz. Ein In-Memory-Adapter kann die Semantik eines echten Auth-Handlers belegen, ohne Postgres-Persistenz oder einen Anbieter-Callback zu beweisen. Verifiziere die konfigurierte Origin, den Callback-Pfad, Session-Wiederherstellung und Abmeldung mit den bereitgestellten Abhängigkeiten, bevor du behauptest, der vollständige Login-Ablauf funktioniere.
- Ungültige Zugangsdaten sowie abgelaufene oder wiederverwendete Verifizierungscodes werden abgelehnt.
- Anonyme und workspaceübergreifende Anfragen erhalten keine Daten mit Besitzbezug.
- Sign-out macht die Session ungültig — ein veralteter Client kann nicht weiter handeln.
- Provisionierte Datensätze bleiben idempotent, wenn Lifecycle-Hooks erneut abgespielt werden.
- Echte Anbieter-Callbacks funktionieren auf der konfigurierten Origin — verifiziert, nicht angenommen.
Häufige Fragen zur Authentifizierung
Die folgenden Fragen tauchen auf, sobald das Login-Formular fertig ist und das System weiterlaufen muss.
- Reicht Middleware, um Routen zu schützen? — Middleware ist eine bequeme Umleitung, keine Autorisierungsschicht. Jede Server-Action und Route löst Session und Workspace selbst auf; Guards auf Seitenebene verstecken Screens, ohne Operationen zu autorisieren.
- Auth selbst bauen oder eine Bibliothek nutzen? — Session-Semantik ist selten der Ort, an dem sich ein SaaS unterscheidet. Eine gewartete Bibliothek wie Better Auth hinter klaren Modulgrenzen liefert geprüfte Bausteine, während die wichtigen Entscheidungen — Scoping, Lifecycle — in deinem Code bleiben.
- Wie hängen Sessions und Workspaces zusammen? — Die Session identifiziert die Person; der Workspace identifiziert die Datensätze, die sie berühren darf. Löse die Mitgliedschaft bei jeder Anfrage serverseitig auf und vertraue nie einer Workspace-ID, die der Client sendet.
- Was erwarten B2B-Kunden von Authentifizierung? — Team-Workspaces mit Rollen, OAuth-Sign-in, Session-Einsicht und -Widerruf sowie einen Audit-Trail. Zwei-Faktor und Passkeys werden für Admin-Rollen zunehmend erwartet.
- Was bricht Authentifizierung in Produktion? — Meist die Ränder: eine Callback-URL, die nur lokal existiert, ein Hook, der doppelt provisioniert, eine Session, die eine Mitgliedschaft überlebt. Teste die Enden der Abläufe, nicht nur die Anfänge.