JWT (JSON Web Token)

Format: Header.Payload.Signature (getrennt durch Punkte). Base64-kodiert (sieht aus wie Buchstabensalat).

• Header: "Ich bin ein JWT, Algorithmus HS256."
• Payload: "User: Max, Rolle: Admin, Ablaufdatum: Morgen."
• Signature: Ein kryptografischer Siegel, das mit einem geheimen Schlüssel erstellt wurde. Wenn Max versucht, "Rolle: Admin" in "Rolle: Gott" zu ändern, passt das Siegel nicht mehr.

Praxisroutine

In der Praxis lernst du JWT (JSON Web Token), indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Stateless Authentication

Der Server muss sich nichts merken (keine Session im RAM). Perfekt für Microservices. Service A stellt das Token aus. Service B (der keine DB hat) prüft nur die Signatur und weiß: "User ist okay." Das skaliert unendlich ("Horizontal Scaling").

2. Das Log-out Problem

Wie sperrt man einen User? Bei Sessions: Einfach Session löschen. Bei JWT: Das Token ist beim User (Browser). Man kann es ihm nicht wegnehmen. Es ist gültig bis zum Ablaufdatum (Expiration). Lösung: Blacklists (Redis) oder sehr kurze Lebensdauer (5 Min) + Refresh Tokens.

Technische Einordnung im System

Technisch ist JWT (JSON Web Token) nicht isoliert. Es wirkt mit Nachbarbegriffen zusammen, hat Voraussetzungen und erzeugt Folgen. Für ein robustes Verständnis prüfst du drei Fragen: Welche Daten oder Bedingungen braucht dieser Schritt? Welche Ausgabe oder Wirkung entsteht? Was passiert bei falschen, fehlenden oder zu großen Eingaben?

Diese Sicht ist wichtig, weil echte Systeme selten am Hauptpfad scheitern. Sie scheitern an Randfällen, Berechtigungen, Zeitpunkten, Formaten, Reihenfolgen oder stillen Annahmen.

1. JWE (JSON Web Encryption) vs. JWS (Signature)

Entwickler verwechseln JWT stetig mit "Verschlüsselung" (Privacy). Ein Standard JWT ist eigentlich ein JWS (JSON Web Signature). Die Daten zirkulieren offen in Base64 (jeder Node/Router kann den HTTP Header mitlesen, wenn das TLS terminiert ist). Zwingen Gesetze, dass das Gesundheits-Token auch von Transit-Middleware unlesbar bleibt, adaptieren Systeme es als JWE (Encryption). Das JWE verpackt das Payload durch Cipher Text und Authenticated Encryption (AES-GCM / ChaCha20) mit einem asymmetrischen CEK (Content Encryption Key Protocol). So blitzt das Token im HTTP Auth Header wie kompletter Zufalls-Salat ohne JSON-Brackets auf. Die Decoderschlüssel besitzten nur jene exakten Edge-Microservices.

2. Signing Algorithmen: HS256 vs. RS256

Die Architektur entscheidet massiv über das symmetrische/asymmetrische Signierverhalten! HS256 (Symmetrisch): Auth-Service signiert durch ein geheimes JWT-Passwort (Shared Secret Hmac-256). Tragödie: Jeder Microservice in deiner K8s-Infrastruktur, der das Puzzlestück verifizieren muss, braucht zwingend exakt selbes Passwort eingespielt. Wenn ein Shop-Service gehackt wird, hat der Angreifer das Token-Signatur-Secret und druckt wild gefälschte Admin-Tickets! Daher Enterprise Standard RS256 (Asymmetrisch, RSA). Auth0/Keycloak haben den Private Key (und nur sie generieren JWTs). Jeder andere Microservice pullet dynamisch (via JWKS-Endpoint .well-known/jwks.json) die völlig gefahrlosen Public Keys runter und checkt die Zertifikatssignatur, ohne jemals selbst Fakes drucken zu können.

3. Token-Revokation Strategien

JWTs sind die Achillesferse der Session-Ungültigkeit, bedingt durch den totalen "Stateless" Aspekt. Ein entlassener Mitarbeiter-Admin besitz ein Token gültig für 60 Minuten. Wie kickt der CISO das Token im Notfall? Variante 1 (Anti-Stateless): Eine Denylist (Redis) mit Token IDs (jti-Claim). Jedes API-Gateway prüft den Hash. Dies zerstört aber komplett die Latenz Vorteile des JWTs. Variante 2 (Rolling Expiry Refresh/Access): Das JWT hat nur 5 Minuten TTL. Nach 5 Min bittet die SPA (Frontend Oauth2/OIDC) das Auth0 Backend passiv im Backchannel per Refresh Token (14 Tage TTL) um Erneuerung. Der CISO nullt in der DB nur den Refresh-Grant. Das JWT verbrennt nach 5 Minuten restlos im RAM tot und der Client stürzt auf einen 401 Unauthenticated Screen, ohne dass die APIs global die DB fragen mussten.