Ein typisches API-Projekt startet klein: Login-Endpoint, ein paar geschützte Routen, fertig. Spätestens mit Mobile-Apps, Single-Page-Frontends oder mehreren Microservices tauchen jedoch Fragen auf: Woher weiß das Backend, wer anfragt? Wie läuft das ohne Session-State? Und wie bleibt das Ganze sicher, wenn Tokens doch „nur Strings“ sind?
JSON Web Token (JWT) ist für diese Aufgaben verbreitet, weil es Identität und Berechtigungen kompakt transportieren kann. Der Mehrwert entsteht aber nicht durch das Format selbst, sondern durch saubere Token-Lebenszyklen, korrekte Validierung und sinnvolle Grenzen: JWT ersetzt keine Autorisierung (was darf der User?) und ist kein Freifahrtschein für „stateless um jeden Preis“.
Wann JWT passt – und wann nicht
Gute Einsatzfälle in Web- und Service-Architekturen
JWT spielt seine Stärken aus, wenn mehrere Backend-Komponenten dieselbe Auth-Information prüfen müssen: API-Gateways, mehrere Services, Edge-Validatoren oder getrennte Frontend-/Backend-Deployments. Ein signiertes Token lässt sich lokal verifizieren, ohne für jede Anfrage eine zentrale Session-Datenbank zu fragen. Das reduziert Kopplung und kann Latenz sparen.
Auch für externe Clients (Mobile, CLI, IoT-Edge) ist ein Bearer-Token praktisch: Der Client muss nur einen Header setzen, keine Cookie-Mechanik und kein serverseitiger Session-State sind zwingend.
Situationen, in denen Cookies oder Sessions einfacher sind
Wenn ausschließlich ein klassisches Server-Rendered-Web (z.B. mit Formular-Login) betrieben wird, sind HTTP-only Cookies mit serverseitiger Session oft die robustere Wahl: Logout ist trivial, Session-Invalidierung sofort, und das Risiko durch Token-Leaks sinkt, weil Tokens nicht im JavaScript-Kontext liegen müssen.
Wer JWT nur nutzt, „weil modern“, erzeugt häufig technische Schulden: ein Token-System mit Refresh-Flow, Sperrlisten, Rotation und Sonderfällen ist komplexer als eine gut gemanagte Session.
Token-Aufbau: Claims, Laufzeiten und Scope-Design
Welche Claims wirklich ins Token gehören
Ein JWT enthält Claims (Felder), die später für Entscheidungen genutzt werden. Minimalistisch bleiben: eine stabile User-ID (sub), Aussteller (iss), Zielgruppe (aud), Ablauf (exp) und Ausstellzeit (iat) sind typische Basisdaten. Rollen und Scopes können sinnvoll sein, aber nur, wenn sich diese Informationen nicht ständig ändern. Häufig wechselnde Berechtigungen gehören eher in eine Datenbankabfrage oder in einen Cache-Layer.
Sensible Daten (E-Mail, interne Flags, gar Passworthashes) gehören nicht ins Token. Ein JWT ist zwar signiert, aber nicht automatisch verschlüsselt: Inhalt kann von Clients gelesen werden. Falls tatsächlich vertrauliche Claims transportiert werden müssen, ist Verschlüsselung ein eigener Mechanismus und sollte als bewusstes Architektur-Element entschieden werden.
Access-Token kurz, Refresh-Token kontrolliert
Bewährt ist ein kurzes Access-Token (z.B. Minutenbereich) und ein langlebigeres Refresh-Token. Der Zugriff auf APIs läuft über das Access-Token, die Erneuerung über Refresh. Das reduziert Schaden bei Token-Diebstahl, weil das Access-Token schnell ausläuft. Gleichzeitig muss der Refresh-Token streng geschützt werden, da er neue Access-Tokens ausstellen kann.
Ein praktisches Design: Access-Token nur in Memory halten (Frontend), Refresh-Token in einem HTTP-only Cookie oder im sicheren Storage eines Mobile-OS. Damit wird die Angriffsfläche durch XSS (Cross-Site Scripting) reduziert.
Signatur, Algorithmen und Key-Management
HS256 vs. RS256: wer signiert, wer validiert?
Bei symmetrischer Signatur (z.B. HS256) teilen sich Aussteller und Validator dasselbe Secret. Das ist in einem Monolithen oder bei wenigen Komponenten handhabbar, skaliert aber organisatorisch schlecht: Jedes System, das validieren soll, muss das Signatur-Secret kennen.
Asymmetrische Signatur (z.B. RS256) trennt Rollen: Der Auth-Service signiert mit Private Key, andere Services validieren mit Public Key. Das passt besser zu verteilten Systemen und reduziert den „Blast Radius“, weil Validatoren keinen Schlüssel besitzen, mit dem sie selbst gültige Tokens ausstellen könnten.
Rotation planen: Keys wechseln ohne Downtime
In der Praxis ist Key-Rotation Pflicht: Secrets leaken, Teams wechseln, Policies ändern sich. Eine robuste Implementierung akzeptiert während einer Übergangszeit mehrere Keys. Dafür wird im Token-Header eine Key-ID (kid) gesetzt, und der Validator lädt den passenden Public Key aus einer kontrollierten Quelle (z.B. aus einer internen Key-Registry oder einem JWKS-Endpoint).
Wichtig: Der Validator darf nicht „blind“ jeder angegebenen kid folgen, sondern muss nur aus einem vorab erlaubten Keyset auswählen. Damit wird verhindert, dass Angreifer Validatoren auf fremde Schlüsselquellen umbiegen.
Validierung im Request-Flow: typische Fehlerbilder
Prüfreihenfolge und harte Abbrüche
Die Validierung sollte deterministisch und vollständig sein: Signatur prüfen, dann Standard-Claims (exp/nbf/iat), dann iss/aud, anschließend eigene Claims (z.B. Tenant-ID). Fehlende oder ungültige Tokens sollten konsequent zu 401 führen; fehlende Berechtigungen zu 403. Diese Trennung hilft Logging, Monitoring und Clients.
Ein häufiger Bug: Tokens werden nur dekodiert, nicht validiert. Dekodieren ist reines Base64-Parsing und liefert keine Vertrauenswürdigkeit. Erst die Signaturprüfung macht Claims belastbar.
Clock Skew und verteilte Systeme
In Multi-Node-Umgebungen unterscheiden sich Systemuhren. Eine kleine Toleranz (Clock Skew) kann sinnvoll sein, darf aber nicht zur „Gummizeit“ werden. Besser: saubere Zeit-Synchronisation (z.B. via NTP) und kurze Toleranzen. Zu großzügige Skews verlängern effektiv die Token-Gültigkeit.
Logout, Sperren und kompromittierte Tokens
Warum „stateless“ oft nicht ganz stimmt
JWT wird gern als stateless verkauft, aber reale Anforderungen erzwingen meist etwas State: Logout, Passwortwechsel, Geräteverlust, Account-Sperre. Ohne State bleibt ein einmal ausgestelltes Token bis exp gültig. Das ist in vielen Produkten nicht akzeptabel.
Gängige Lösung: Access-Token kurz halten und Refresh-Token serverseitig tracken. Der Server speichert Refresh-Tokens (oder deren Hashes) pro Gerät/Session, inklusive Ablauf, Client-Metadaten und Status. Wird ein Refresh-Token widerrufen, endet die „Session“ effektiv beim nächsten Refresh.
Token-Rotation und Wiederverwendung erkennen
Refresh-Token sollten bei jeder Nutzung rotiert werden: Client sendet Refresh-Token, Server stellt neues Access-Token und neues Refresh-Token aus, das alte Refresh-Token wird invalidiert. Taucht ein altes Refresh-Token erneut auf, ist das ein starkes Signal für Diebstahl. Dann ist ein aggressives Gegenmaß sinnvoll: alle Sessions des Users oder mindestens die betroffene Geräte-Session sperren.
Frontend-Integration: Storage, CORS und CSRF sauber lösen
Token-Storage ohne unnötige Angriffsfläche
Access-Tokens im LocalStorage sind bequem, aber XSS kann sie auslesen. Besser ist In-Memory-Storage (z.B. in einer Frontend-State-Engine) und ein Refresh-Token im HTTP-only Cookie. Das ist nicht „magisch sicher“, aber reduziert typische Token-Exfiltration durch Script-Injection deutlich.
Wenn Cookies genutzt werden, muss CSRF (Cross-Site Request Forgery) adressiert werden, weil Browser Cookies automatisch mitsenden. Eine gängige Abwehr: SameSite=strict/lax passend wählen, dazu CSRF-Tokens für state-changing Requests, plus origin/referrer-Prüfungen. Bei reinen Bearer-Tokens im Header ist CSRF meist weniger relevant, XSS dafür umso mehr.
CORS-Regeln nicht zu offen konfigurieren
Viele Projekte öffnen CORS reflexartig auf „*“. Das ist selten nötig und oft riskant, sobald Credentials (Cookies) beteiligt sind. CORS sollte explizite Origins erlauben (Dev, Staging, Prod) und nur die benötigten Methoden/Header freigeben. Preflight-Requests gehören in Load-Tests, weil sie bei falscher Konfiguration Performance-Probleme erzeugen können.
Einsetzbare Schritte für ein robustes Setup
In Projekten mit mehreren Clients und längerer Produktlebensdauer hat sich folgender Ablauf bewährt. Die Punkte sind bewusst konkret gehalten und lassen sich in Node.js, Java, .NET oder Go ähnlich umsetzen:
- Access-Token kurz halten (Minutenbereich) und ausschließlich für API-Zugriff verwenden.
- Refresh-Token Rotation implementieren und serverseitig Refresh-Tokens (oder Hashes) pro Gerät/Session speichern.
- JWT-Validierung zentral als Middleware/Filter umsetzen: Signatur, exp/nbf, iss/aud, danach Rollen/Scopes prüfen.
- Asymmetrische Signatur erwägen, wenn mehrere Services validieren: Validatoren bekommen nur Public Keys.
- CORS strikt konfigurieren und für Cookie-basierte Refresh-Flows SameSite/CSRF-Strategie festlegen.
- Security-Logging ergänzen: fehlgeschlagene Validierungen, Refresh-Reuse, ungewöhnliche Geos/Devices (ohne personenbezogene Inhalte zu loggen).
- Testfälle aufnehmen: abgelaufenes Token, falsche aud/iss, falscher kid, gesperrter Refresh-Token, parallele Refresh-Requests.
Vergleich: Bearer-Token im Header vs. Cookie-basierter Refresh
| Aspekt | Bearer-Token (Header) | Refresh im HTTP-only Cookie |
|---|---|---|
| XSS-Risiko | Hoch, wenn Token in Web-Storage liegt | Niedriger, Cookie ist nicht per JS lesbar |
| CSRF-Risiko | Meist gering (Token nicht automatisch gesendet) | Relevanter, Schutz via SameSite/CSRF nötig |
| Implementierungsaufwand | Einfacher, aber sauberer Storage/Refresh oft vergessen | Etwas höher, dafür klarer Lifecycle |
| Mobile/CLI | Sehr gut geeignet | Cookie-Modell je nach Client weniger passend |
Tests und Betrieb: was in CI/CD wirklich helfen kann
Automatisierte Tests auf Token-Flows
Für Auth lohnt sich Integration-Testing mehr als reines Unit-Testing: Token ausstellen, API callen, Refresh durchführen, widerrufen, erneut refreshen. Damit werden Race Conditions sichtbar, etwa wenn zwei parallele Requests denselben Refresh-Token nutzen. Hier sollte der Server deterministisch reagieren (z.B. ein Request gewinnt, der andere bekommt 401 und muss neu anmelden).
Auch negative Tests sind wichtig: falsche Signatur, falscher Algorithmus, manipulierte Claims. Validierer sollten bei jeder Abweichung hart ablehnen, statt „best effort“ zu fahren.
Beobachtbarkeit statt Token-Inhalte zu loggen
Tokens sollten nicht im Klartext geloggt werden. Für Debugging reichen Korrelations-IDs, anonymisierte User-IDs und Event-Typen (login_success, token_invalid_signature, refresh_reuse_detected). In verteilten Setups helfen strukturierte Logs und Metriken: Anzahl 401/403, Refresh-Fehlerquoten, Latenzspitzen durch Key-Lookups.
