HTTP ist zustandslos — wie funktionieren dann Sitzungen?
Kurzantwort
HTTP ist zustandslos — jede Anfrage ist unabhängig und hat keine Erinnerung an vorherige. Sitzungen fügen darauf Zustand hinzu: Nach der Anmeldung gibt der Server eine Kennung aus, die der Browser in einem Cookie speichert und bei jeder Anfrage erneut sendet. Serverseitige Sitzungen halten den Zustand auf dem Server, indiziert über eine undurchsichtige Sitzungs-ID; zustandslose Tokens wie JWTs legen signierten Zustand in das Token selbst, sodass der Server ohne Speicher prüfen kann.
HTTP ist von Natur aus zustandslos: Jede Anfrage steht für sich, und der Server behält keine eingebaute Erinnerung daran, wer die vorherige gesendet hat. Diese Einfachheit skaliert hervorragend, kollidiert aber mit dem Bedürfnis, „angemeldet" zu bleiben. Sitzungen sind die Schicht, die einem zustandslosen Protokoll Identitätskontinuität hinzufügt.
Der zentrale Mechanismus
Nachdem du dich einmal authentifiziert hast, gibt der Server eine Kennung aus, und der Browser speichert sie — fast immer in einem Cookie. Da Browser Cookies automatisch an jede weitere Anfrage an diese Website anhängen, kann der Server dich bei jeder Anfrage erkennen, ohne dass du dich erneut authentifizierst. Das Cookie ist ein Inhaber-Berechtigungsnachweis, weshalb seine Attribute (HttpOnly, Secure, SameSite) so wichtig sind.
Zwei Wege, den Zustand zu halten
Serverseitige Sitzungen (zustandsbehaftet). Das Cookie enthält eine undurchsichtige, zufällige Sitzungs-ID. Der Server hält die eigentlichen Sitzungsdaten (Nutzer-ID, Rollen, Ablauf) in seinem eigenen Speicher — Arbeitsspeicher, Redis, eine Datenbank — indiziert über diese ID. Vorteile: Der Server kann eine Sitzung sofort widerrufen, indem er sie löscht, und keine sensiblen Daten liegen im Cookie. Kosten: Der Server (oder ein gemeinsamer Speicher) muss Zustand halten, was beim horizontalen Skalieren Infrastruktur erfordert.
Zustandslose Tokens (z. B. JWT). Das Token selbst trägt die Claims (Nutzer, Rollen, Ablauf) und ist kryptografisch signiert. Der Server prüft die Signatur bei jeder Anfrage und vertraut dem Inhalt — kein Nachschlagen nötig. Vorteile: Skaliert leicht über viele Server ohne gemeinsamen Sitzungsspeicher. Kosten: Das Token ist bis zum Ablauf gültig, also ist der Widerruf schwierig (du brauchst eine Sperrliste oder kurze Lebensdauern plus Refresh-Tokens), und übergroße oder sensible Claims können durchsickern.
Warum die ID unvorhersehbar sein muss
Ob undurchsichtige ID oder signiertes Token: Kann ein Angreifer sie erraten, per Brute Force ermitteln oder fälschen, kapert er die Sitzung. Sitzungs-IDs müssen daher lang sein und aus einem CSPRNG stammen, und Tokens müssen eine starke Signatur mit serverseitig festgelegtem Algorithmus verwenden.
Prüfer achten darauf, dass HTTP zustandslos ist und Cookies eine Kennung tragen, auf die Abwägung zustandsbehaftet vs. zustandslos (Widerruf vs. Skalierbarkeit) und auf die Sicherheitsanforderung, dass die Kennung nicht erratbar sein darf.
Wahrscheinliche Anschlussfragen
- Welche Abwägungen gibt es zwischen serverseitigen Sitzungen und zustandslosen JWTs?
- Wie widerruft man ein zustandsloses JWT vor seinem Ablauf?
- Warum muss eine Sitzungs-ID lang und unvorhersehbar sein?