Cookies, Sessions, Tokens – woher weiß eine Webseite eigentlich, dass ich noch eingeloggt bin?

Guter Einstieg, denn genau das ist der Widerspruch, den die Technik auflöst. HTTP selbst merkt sich nichts. Jede Anfrage ist für den Server erst mal neu. Also muss der Browser bei jeder Anfrage etwas mitschicken, woran der Server dich wiedererkennt.

Variante 1: Session + Cookie (serverseitiger Zustand)

1. Du loggst dich ein, der Server prüft das Passwort.
2. Der Server legt eine Session an, also einen Datensatz bei sich („Sitzung 8f3a… gehört zu Sophie, eingeloggt seit 18:02“).
3. Zurück an den Browser geht nur die Session-ID, gespeichert in einem Cookie.
4. Bei jedem weiteren Klick schickt der Browser das Cookie automatisch mit, und der Server schlägt die ID nach.

Das heißt: Das Cookie ist nur der Transportbehälter, die Session ist der Zustand auf dem Server. Nicht dasselbe.

Variante 2: Token, z. B. JWT (Zustand steckt im Token)

Hier speichert der Server nichts. Er gibt dir nach dem Login ein signiertes Token, in dem schon drinsteht, wer du bist und bis wann es gilt. Bei jeder Anfrage wird das Token mitgeschickt (oft im Authorization-Header), und der Server prüft nur die Signatur. Das ist praktisch bei APIs, Apps und verteilten Systemen, weil kein zentraler Session-Speicher nötig ist.

Der klassische Trade-off für die Klausur:

• Session: leicht widerrufbar (Server löscht die Session → sofort ausgeloggt), aber der Server muss Zustand halten.
• Token: skaliert gut und ist zustandslos, aber ein ausgestelltes Token bleibt bis zum Ablauf gültig. Deshalb gibt es kurze Laufzeiten plus Refresh-Token.

Merksatz: Session = Server merkt sich dich. Token = du trägst deinen Ausweis selbst mit. Das Cookie ist nur eine Möglichkeit, das eine oder andere mitzuschicken.

Noch die Sicherheits- und die Cookie-Banner-Seite, weil das in Klausuren gern als Transferfrage kommt:

Warum ist die Session-ID so wertvoll?

Wer sie hat, ist für den Server du, ganz ohne Passwort (Session Hijacking). Deshalb setzt man beim Cookie Schutzattribute:

• HttpOnly: JavaScript kommt nicht an das Cookie ran. Das schützt vor dem Auslesen per eingeschleustem Skript (XSS).
• Secure: Das Cookie wird nur über HTTPS übertragen.
• SameSite: Der Browser schickt das Cookie bei Anfragen von fremden Seiten nicht (oder nur eingeschränkt) mit. Das hilft gegen CSRF, also wenn eine fremde Seite deinen Browser unbemerkt Aktionen in deinem Konto ausführen lässt.

Dazu kommen: neue Session-ID direkt nach dem Login, Timeout bei Inaktivität, und beim Logout die Session auf dem Server wirklich löschen, nicht nur das Cookie im Browser.

Und die Cookie-Banner?

Rechtlich geht es darum, ob etwas auf deinem Gerät gespeichert oder ausgelesen wird. Technisch unbedingt erforderliche Cookies, wie genau so ein Login-Session-Cookie oder der Warenkorb, brauchen keine Einwilligung. Einwilligungspflichtig sind z. B. Tracking- und Werbe-Cookies. Deshalb kannst du dich auch einloggen, wenn du im Banner alles ablehnst. Genau diese Unterscheidung „technisch notwendig vs. optional“ kennst du aus dem Marketing ja von der anderen Seite. 😉