Authentifizierung und Sessions

Authentifizierung und Sessions

0:00 In diesem Modul klären wir, wer eigentlich vor dem Bildschirm sitzt — und wie die Anwendung sich das über mehrere Seitenaufrufe hinweg merkt. Das ist ein Thema, bei dem ich Ihnen den Weg zu Fuß zeigen möchte, obwohl es dafür ausgezeichnete Bibliotheken gibt. Der Grund ist einfach: Wer einmal selbst eine Sitzung gebaut hat, konfiguriert eine Bibliothek richtig, statt ihr zu vertrauen.

0:22 Wir bauen also Anmeldung, Sitzung und Abmeldung selbst, sehen uns die Alternativen an und ordnen am Ende ein, wann man welchen Weg gehen sollte. Berechtigungen kommen im nächsten Modul — die sind nämlich etwas anderes.

Die drei Begriffe auseinanderhalten

0:34 Beginnen wir mit drei Wörtern, die im Alltag munter durcheinandergehen und drei verschiedene Dinge bezeichnen. Diese Unterscheidung ist keine Begriffsreiterei: Jede Vermischung führt zu einer konkreten Lücke, und ich zeige Ihnen gleich, welche. Wer die drei sauber trennt, hat die halbe Sicherheitsarchitektur schon im Kopf.

0:53 Authentifizierung klärt, wer jemand ist — der Blick auf den Ausweis. Sitzungsverwaltung hält diesen Zustand über Anfragen hinweg — das Bändchen am Handgelenk, das Sie beim Festival nicht bei jedem Getränk neu ausweisen lässt. Und Autorisierung entscheidet, was diese Person darf — ob das Bändchen auch für den Backstage-Bereich gilt. Drei Dinge, drei Zeitpunkte, drei Mechanismen.

1:16 Die ersten beiden behandeln wir heute, das dritte im nächsten Modul. Diese Trennung durchzuhalten ist wichtiger, als sie zunächst wirkt. Sehen Sie sich die mittlere Spalte an — die Fragen sind wirklich verschieden. Wer bist du, bist du noch da, was darfst du. Und weil sie verschieden sind, brauchen sie verschiedene Antworten.

1:36 Der praktische Nutzen dieser Aufteilung zeigt sich bei Änderungen: Wenn Sie später von Passwörtern auf eine Anmeldung über einen Fremdanbieter wechseln, betrifft das nur die erste Zeile. Sitzung und Berechtigungen bleiben, wie sie sind. Wer alles vermischt hat, baut in so einem Fall die halbe Anwendung um. Der erste Punkt ist die häufigste Vermischung überhaupt: Eine gültige Sitzung sagt nichts über Berechtigungen aus. Jemand ist angemeldet — na und? Angemeldet sind alle Gäste.

2:05 Der zweite Punkt ist subtiler und wird uns im nächsten Modul noch beschäftigen: Eine Rolle im Cookie ist eine Behauptung, kein Nachweis. Das Cookie liegt im Browser des Nutzers, und auch wenn es signiert ist, beschreibt es den Stand von damals. Und der dritte fasst zusammen, was passiert, wenn man angemeldet mit berechtigt gleichsetzt: Dann darf jeder alles.

Anmeldung über Server Actions

2:26 Jetzt bauen wir die Anmeldung — und zwar mit dem Werkzeug aus Modul sieben. Das ist kein Zufall: Eine Server Action ist für diesen Fall bemerkenswert gut geeignet, und zwar aus einem Grund, der über Bequemlichkeit hinausgeht. Sehen wir uns den Ablauf an und danach, warum dieser Weg sicherer ist als das, was viele aus Client-Anwendungen gewohnt sind.

2:47 Der Ablauf ist geradlinig: Eingaben validieren, Zugangsdaten prüfen, Sitzung anlegen, weiterleiten. Vier Schritte, und alle vier laufen auf dem Server. Passwörter werden dabei gehasht gespeichert, niemals im Klartext — und mit einem Verfahren, das für Passwörter gemacht ist, nicht mit einer schnellen Prüfsumme. Der Unterschied ist erheblich: Ein gutes Passwortverfahren ist absichtlich langsam, damit massenhaftes Durchprobieren teuer wird.

3:13 Eine schnelle Prüfsumme ist genau das Gegenteil und macht einen gestohlenen Datenbestand in Stunden lesbar. Achten Sie auf den Kommentar unter dem Code, denn er beschreibt ein Detail mit Folgen: eine gemeinsame Fehlermeldung für beide Fälle. Wenn Sie unterscheiden zwischen Nutzer unbekannt und Passwort falsch, verraten Sie, welche E-Mail- Adressen bei Ihnen registriert sind.

3:35 Das klingt harmlos und ist es nicht — für eine Marina wäre das die Information, wer dort Kunde ist. Worauf es ankommt: Die Meldung ist bewusst unscharf, obwohl Ihnen die genaue Ursache bekannt ist. Loggen dürfen Sie sie natürlich, nur eben nicht zurückgeben. Der Kern steckt in den ersten beiden Punkten: Zugangsdaten wandern nicht durch clientseitigen Code.

3:56 Bei einem klassischen Aufruf gegen eine eigene Anmelde- Schnittstelle liegen Passwort und Antwort kurzzeitig in JavaScript im Browser — und was dort liegt, kann eine kompromittierte Bibliothek mitlesen. Hier gibt es diesen Zwischenschritt nicht. Der vierte Punkt ist der, den man leicht übersieht: Es entsteht kein zusätzlicher öffentlicher Endpunkt, den jemand absichern und pflegen müsste.

4:18 Weniger Zugänge bedeutet weniger Angriffsfläche — das ist eine einfache, aber verlässliche Rechnung. Der zweite Punkt ist der, den ich in Übungsprojekten fast immer vermisse: Ohne Ratenbegrenzung ist die Anmeldung dem Durchprobieren offen. Jemand nimmt eine Liste bekannter Passwörter und arbeitet sie ab — automatisiert, tausend Versuche in der Minute.

4:39 Eine Sperre nach fünf Fehlversuchen macht das unmöglich, und sie kostet Sie zwanzig Zeilen. Der dritte Punkt ist eine Wiederholung, die es verdient: Ein Passwortverfahren, kein schneller Hash. Wer hier den falschen Baustein wählt, merkt das erst, wenn die Datenbank abhandengekommen ist.

Zustandslose Sitzungen

4:56 Jetzt zur Sitzung selbst, und zwar in der einfacheren von zwei Varianten. Die Sitzung liegt dabei im Cookie — signiert, verschlüsselt, beim Nutzer. Das klingt zunächst gewagt und ist ein etabliertes Verfahren, wenn man ein paar Regeln einhält. Diese Regeln sehen wir uns genau an, denn sie sind kein Beiwerk. Sie brauchen drei Dinge: ein Geheimnis aus den Umgebungsvariablen, eine Bibliothek zum Signieren und die Cookie-Schnittstelle von Next.js.

5:23 Ins Cookie gehört das Minimum — Benutzerkennung und Rolle, sonst nichts. Keine Namen, keine Adressen, keine Telefonnummern. Der Grund ist einfach: Das Cookie liegt im Browser des Nutzers und wird bei jeder Anfrage mitgeschickt. Es ist zwar verschlüsselt, aber es ist eben nicht in Ihrem Haus. Behandeln Sie es wie eine Postkarte in einem verschlossenen Umschlag — der Umschlag hilft, aber man schreibt trotzdem nicht alles darauf.

5:49 Die interessanten Zeilen stehen im unteren Block: fünf Optionen für das Cookie, und keine davon ist Beiwerk. Was hier passiert, ist eigentlich simpel — ein Wert wird verschlüsselt und gesetzt. Worauf es ankommt, ist die Sorgfalt bei diesen Optionen. Sie sind der Unterschied zwischen einer Sitzung, die man stehlen kann, und einer, die man nicht stehlen kann.

6:09 Und weil man sie beim Schreiben so leicht weglässt — es funktioniert ja auch ohne — sehen wir sie uns einzeln an. Diese Tabelle steht bewusst so da: links die Option, rechts der Angriff, den sie verhindert. Das ist die einzig sinnvolle Art, sie zu lernen. Die erste verhindert, dass fremdes JavaScript im Browser das Cookie ausliest — das ist Ihr Schutz gegen Cross-Site-Scripting, der auch dann noch greift, wenn anderswo etwas schiefgeht.

6:35 Die dritte verhindert, dass das Cookie bei Aufrufen von fremden Seiten mitgeschickt wird. Der Satz unter der Tabelle ist ernst gemeint: Fehlt eine davon, ist die Sitzung auf eine bestimmte, benennbare Weise angreifbar. Es sind keine Empfehlungen. Der zweite Punkt ist der Satz, den ich Ihnen aus diesem Kapitel mitgeben möchte: Ein Cookie wird vom Nutzer transportiert und ist niemals vertrauenswürdig.

6:59 Es ist signiert, das heißt, es wurde nicht verändert. Es heißt nicht, dass es noch gültig ist oder dass die darin genannte Rolle noch stimmt. Der dritte Punkt ist handwerklich und trotzdem regelmäßig Ursache für Vorfälle: Das Signaturgeheimnis gehört in die Umgebung, nicht ins Repository. Ein Geheimnis in der Versionsgeschichte ist dauerhaft kompromittiert, auch nach dem Löschen.

Sitzungen in der Datenbank

7:21 Jetzt die zweite Variante — aufwendiger, dafür mit einer Eigenschaft, die der ersten grundsätzlich fehlt. Ich stelle beide nebeneinander, statt eine zu empfehlen, denn die Wahl hängt davon ab, was Ihre Anwendung tut. Für ein Portal mit Verwaltungsrollen fällt sie oft anders aus als für einen Blog. Bei dieser Variante liegt die Sitzung in Ihrer Datenbank, und der Browser bekommt nur eine verschlüsselte Kennung.

7:46 Das ist mehr Arbeit: eine Tabelle, ein Aufräummechanismus, eine zusätzliche Abfrage bei jeder Prüfung. Dafür bekommen Sie drei Dinge, die zustandslos nicht gehen — Abmeldung auf allen Geräten, eine Übersicht der aktiven Sitzungen und den sofortigen Entzug. Es ist der Unterschied zwischen einem Festivalbändchen, das man nicht mehr einsammeln kann, und einem Schlüssel, den Sie zentral sperren.

8:08 Die zweite Zeile ist die entscheidende, alle anderen sind Aufwandsfragen. Sofort widerrufbar oder nicht — daran hängt die Wahl. Und die letzte Zeile fasst zusammen, wann sich das lohnt: Bei einem Portal mit Verwaltungsrechten ist die rechte Spalte oft richtig. Denken Sie an unsere Marina: Wenn ein Mitarbeiter das Unternehmen verlässt, wollen Sie seinen Zugang zur Rechnungsübersicht in dem Moment beenden, in dem Sie es entscheiden — und nicht dann, wenn zufällig sein Cookie abläuft.

8:36 Rechnen wir das durch, denn die Konsequenz ist konkreter, als sie klingt. Eine zustandslose Sitzung mit sieben Tagen Laufzeit bedeutet: Ein gesperrter Zugang funktioniert im schlechtesten Fall noch sieben Tage. Der Mitarbeiter ist entlassen, die Sperre ist gesetzt, und er kommt trotzdem an die Rechnungen. Sie können die Laufzeit verkürzen, dann müssen sich alle ständig neu anmelden — ein schlechter Tausch. Mit Datenbanksitzungen ist der Entzug eine gelöschte Zeile und wirkt sofort.

9:03 Für die meisten Geschäftsanwendungen ist das das Argument, das den Ausschlag gibt.

Sitzung erneuern und beenden

9:09 Zwei kurze Vorgänge, die man leicht als Nebensache behandelt und die beide ihre Tücken haben. Beim Erneuern geht es um die Balance zwischen Bequemlichkeit und Sicherheit. Beim Beenden geht es darum, dass tatsächlich beendet wird, was beendet werden soll — und da gibt es je nach Variante einen Unterschied. Eine Sitzung, die bei Aktivität verlängert wird, hält aktive Nutzer angemeldet, ohne dass Sie die Ablaufzeit generell strecken müssen.

9:34 Wer täglich vorbeischaut, bleibt drin; wer drei Wochen nicht da war, meldet sich neu an. Das ist die sinnvolle Mitte. Beim Abmelden wird das Cookie gelöscht — und bei Datenbanksitzungen zusätzlich der Eintrag. Dieses Zusätzlich ist der Punkt, an dem ich gleich noch einmal nachhake, denn es wird regelmäßig vergessen. Kurz und unspektakulär: Cookie löschen, weiterleiten. Aber lesen Sie die Fußnote, denn sie beschreibt einen echten Fehler.

10:01 Bei Datenbanksitzungen genügt das Löschen des Cookies nicht — der Eintrag in der Datenbank gilt weiter. Wer das Cookie irgendwo gespeichert hat, ist damit weiterhin angemeldet. Der Nutzer hat sich abgemeldet, das System sieht das anders. Worauf es ankommt: Der Abmeldeweg muss zu Ihrer Sitzungsvariante passen. Das ist einer der Fälle, in denen ein halber Umbau schlimmer ist als gar keiner.

10:26 Der erste und zweite Punkt hängen zusammen und sind eine Designentscheidung von Next.js, die ich für richtig halte: Cookies dürfen beim Rendern nicht gesetzt werden. Das Framework verhindert es. Der Grund ist, dass Rendern beliebig oft passieren kann — auch bei einem Vorabladen, das der Nutzer nie sieht. Eine Abmeldung, die dabei ausgelöst würde, wäre ein Geist im System.

10:47 Der vierte Punkt ist eine nützliche Eigenschaft: Nach dem Setzen eines Cookies rendert Next.js die Seite serverseitig neu, damit die Oberfläche den neuen Stand zeigt.

Auth-Bibliotheken einordnen

10:57 Jetzt der Moment, in dem ich Ihnen sage, dass Sie das alles wahrscheinlich nicht selbst bauen sollten. Das ist kein Widerspruch zu den letzten fünf Kapiteln, sondern ihr Zweck: Sie sollten wissen, was eine Bibliothek für Sie tut, bevor Sie ihr das Wichtigste Ihrer Anwendung anvertrauen. Sehen wir uns an, wo die Grenze verläuft.

11:16 Die Dokumentation empfiehlt für Produktivsysteme ausdrücklich eine Bibliothek und nennt gleich ein gutes Dutzend davon — von selbst gehosteten Lösungen bis zu Diensten. Sie bringen mit, was wir hier nicht gebaut haben: Anmeldung über Fremdanbieter, Mehrfaktor-Authentifizierung, Rollenmodelle, das Zurücksetzen von Passwörtern.

11:34 Das sind keine Nebensächlichkeiten, sondern die Themen, an denen man Wochen verbringen kann. Und es sind genau die Themen, bei denen eigene Fehler teuer werden. Der erste Punkt ist mein eigentliches Argument: Wer den Ablauf kennt, konfiguriert die Bibliothek richtig statt blind. Diese Werkzeuge haben Dutzende Einstellungen, und einige davon sind Sicherheitsentscheidungen — Ablaufzeiten, Cookie-Optionen, was in einem Token landet.

11:59 Wenn Sie wissen, was diese Optionen bewirken, treffen Sie bewusste Entscheidungen. Wenn nicht, übernehmen Sie Vorgaben und hoffen. Der dritte Punkt ist die praktische Kehrseite: Fehler in fremder Konfiguration erkennt nur, wer weiß, was eigentlich passieren soll. Lesen Sie diese Tabelle als Aufwandsschätzung. Die unteren Zeilen sind machbar — Sitzungsverwaltung haben wir gerade in einem Kapitel gebaut.

12:23 Die oberen sind es nicht: Anmeldung über Fremdanbieter und Mehrfaktor selbst zu bauen kostet Wochen und bringt Risiken, die man kaum überblickt. Meine Einschätzung: Wenn Ihre Anwendung nur Anmeldung mit Passwort braucht, ist der eigene Weg vertretbar. Sobald ein zweiter Faktor oder eine Fremdanmeldung dazukommt, nehmen Sie eine Bibliothek. Der Umstieg später ist teurer als die Entscheidung jetzt.

12:47 Der erste Punkt ist einer, der in deutschen Projekten oft übersehen wird: Ein Dienst als Anbieter bedeutet Auftragsverarbeitung und meistens Drittlandtransfer. Das ist keine technische Frage, sondern eine rechtliche — und sie sollte mitentschieden werden, nicht nachträglich auffallen. Gerade bei einem Portal mit Kundendaten ist das relevant.

13:06 Der dritte Punkt ist die praktische Konsequenz aus allem: Ein Wechsel später ist teuer, weil Sitzungen, Nutzerkonten und Passwörter migriert werden müssen. Deshalb gehört die Entscheidung an den Anfang.

Sitzungsdaten und Streaming

13:18 Zum Abschluss die Verbindung zurück zu Modul fünf. Sitzungsdaten haben eine unangenehme Eigenschaft: Sie werden fast immer in der Kopfzeile gebraucht, also in einem Layout, das auf jeder Seite erscheint. Und genau dort richtet ein unbedachter Zugriff den größten Schaden an. Das ist der häufigste Auslöser für langsame Navigationen überhaupt.

13:39 Ein Warten auf die Sitzung ganz oben im Layout verzögert den ersten gestreamten Abschnitt — und hält alle Kinder dahinter auf. Das ist besonders ärgerlich, weil es fachlich vollkommen richtig aussieht: Das Benutzermenü gehört nach oben, also liest man die Sitzung dort. Nur muss der Zugriff nicht dort stehen, wo das Menü steht. Diese beiden Dinge lassen sich trennen, und genau das ist die Lösung.

14:01 Die Regel aus Modul fünf gilt hier in ihrer wirksamsten Form: Zugriff so tief wie möglich. Der Unterschied zur naiven Fassung ist eine einzige Zeile: Das Layout ist nicht mehr asynchron, und der Zugriff sitzt in einer eigenen kleinen Komponente hinter einer Suspense-Grenze. Navigation und Inhalt gehen sofort raus, nur das Benutzermenü erscheint einen Wimpernschlag später.

14:24 Worauf es ankommt: Das kostet Sie eine zusätzliche Komponente und ein Gerüst als Platzhalter. Dafür ist jede einzelne Seite Ihrer Anwendung sofort da statt nach der Sitzungsabfrage. Ich kenne wenige Änderungen mit einem besseren Verhältnis von Aufwand zu Wirkung. Der erste Punkt beschreibt eine Grenze, an die Sie zwangsläufig stoßen: Client-Komponenten können den Zugriffs-Layer nicht importieren — der ist serverseitig festgenagelt, wie wir in Modul neun gebaut haben.

14:51 Werte müssen also von einer übergeordneten Server-Komponente kommen, als Eigenschaft oder über einen Kontext. Und der dritte Punkt ist der wichtige Zusatz dazu: Sensible Sitzungsfelder gehören dabei markiert, damit sie den Client gar nicht erst erreichen können. React bietet dafür Werkzeuge, die wir uns im nächsten Modul ansehen.

15:09 In dieser Aufgabe bauen Sie den vollständigen Ablauf: anmelden, neu laden, abmelden. Der Erfolg hat zwei Teile, und der zweite ist der, den ich prüfen würde: Das Cookie trägt alle fünf Optionen. Sehen Sie in den Entwicklerwerkzeugen nach, dort stehen sie. Und beachten Sie die Notiz — die Rollen kommen im nächsten Modul. Wir bauen hier bewusst nur die ersten beiden der drei Ebenen vom Anfang des Moduls.

15:34 Wer sie schon jetzt vermischt, muss später auseinanderdröseln.

Modul 10 zusammengefasst

15:38 Vier Sätze zum Mitnehmen. Authentifizierung, Sitzung und Autorisierung sind drei verschiedene Dinge. Die Anmeldung läuft als Server Action, damit Zugangsdaten den Server nie verlassen. Jede Cookie-Option verhindert einen konkreten Angriff — es sind keine Empfehlungen. Und Sitzungsdaten im Layout gehören hinter eine eigene Suspense-Grenze. Im nächsten Modul kommt die dritte Ebene: Wer darf was, und wo wird das geprüft?

16:04 Dort zahlen sich der Zugriffs- Layer aus Modul neun und die Layout-Eigenschaft aus Modul zwei gleichzeitig aus.