JWT – JSON Web Tokens
In L4 hast du die einfachen Auth-Verfahren – API-Key und Basic Auth – kennengelernt. Beide haben den gleichen Nachteil: das Geheimnis wandert bei jedem Request mit. In modernen Architekturen mit Microservices ist das unpraktisch: jeder Service müsste die User-Datenbank kennen.
Die elegante Antwort darauf heißt JWT – JSON Web Tokens. Das ist heute das de-facto-Standard-Verfahren für API-Authentifizierung in modernen Web- und Mobile-Anwendungen. Diese Lektion erklärt die Mechanik: was JWTs sind, wie sie aussehen, wie die Signatur funktioniert, wie der Auth-Flow läuft, und welche Sicherheits-Fallen lauern.
1) Die Grundidee: ein „Ausweis" mit Verfallsdatum
Eine passende Analogie: ein JWT ist wie ein VIP-Wristband im Festival. Beim Einlass zeigst du einmalig deinen Ausweis (Login mit Passwort), und bekommst dafür ein Band ums Handgelenk. Das Band ist nicht fälschbar (eindeutig codiert) und hat ein klares Verfallsdatum. Bei jedem weiteren Zugang (Bühne A, Backstage, Catering) musst du nicht mehr deinen Ausweis zeigen – das Band reicht. Sicherheitsleute verifizieren das Band, ohne dich erneut zu identifizieren.
Genau so funktioniert JWT: der Client meldet sich einmal mit Username/Passwort an. Der Server schickt einen Token zurück. Bei jedem folgenden API-Aufruf schickt der Client diesen Token mit – und der Server prüft die Signatur, ohne die User-Datenbank zu fragen.
2) JWT im HTTP-Request
So sieht ein JWT in einem typischen API-Aufruf aus – im Authorization-Header mit dem Schlüsselwort Bearer:
GET /api/orders HTTP/1.1 Host: shop.example.com Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI3IiwibmFtZSI6IkFubmEifQ.9jR2hN6P8YfQ2WqK1m3z...
Das Schema-Wort Bearer (englisch für „Überbringer") sagt: „wer diesen Token hat, ist berechtigt". Identität wird über die Signatur verifiziert.
3) Die drei Teile eines JWT
Ein JWT besteht aus drei mit Punkten getrennten Teilen: Header, Payload und Signature. Jeder Teil ist Base64URL-kodiertes JSON:
4) JWT decodieren: spiel selbst damit
Bevor wir tiefer einsteigen, dekodiere selbst einen Token. Header und Payload werden live dekodiert. Das ist nichts Magisches – nur Base64 und JSON:
5) Die wichtigsten Claims
Die JSON-Felder im Payload heißen Claims. Es gibt drei Sorten: Registered (vom RFC vorgesehen, kurze Namen), Public (öffentlich registriert) und Private (frei wählbar). Die registrierten Claims sind in IHK-Klausuren beliebt:
| Claim | Bedeutung | Beispiel |
|---|---|---|
| iss | Issuer – wer hat das Token ausgestellt? | "shop.example.com" |
| sub | Subject – um welchen User geht es? | "7" (User-ID) |
| aud | Audience – für welche Anwendung? | "shop-api" |
| exp | Expiration – Ablauf als Unix-Timestamp | 1715938000 |
| nbf | Not Before – frühester gültiger Zeitpunkt | 1715900000 |
| iat | Issued At – Ausstellungs-Zeitpunkt | 1715900000 |
| jti | JWT ID – eindeutige Token-ID (Revocation) | "a8f2-..." |
name, role, permissions, tenant_id. Achtung bei exp: das ist ein Unix-Timestamp in Sekunden (nicht Millisekunden!). Wer JavaScript-typische Millisekunden reinschreibt, hat Tokens, die im Jahr 56000 ablaufen. Library-Bugs in diesem Bereich passieren regelmäßig.6) Die Signatur – das Anti-Fälschungs-Siegel
Die Signatur ist das, was JWT wirklich sicher macht. Sie wird so berechnet:
signature = HMACSHA256( base64url(header) + "." + base64url(payload), geheimes_secret )
Der Server kombiniert Header und Payload, hängt das Geheimnis (das nur er kennt) an, und bildet einen Hash. Bei jedem Eingang prüft er die Signatur erneut: stimmt sie? Dann ist der Token echt. Stimmt sie nicht? Manipulation oder gefälscht – ab in den Müll. Vgl. K11 Hashing.
Es gibt zwei Familien von Signatur-Algorithmen:
- HS256 / HS384 / HS512 (HMAC-basiert): symmetrisch. Server signiert und verifiziert mit demselben Geheimnis. Einfach, schnell – aber alle Beteiligten brauchen das Geheimnis.
- RS256 / RS384 / RS512 (RSA-basiert): asymmetrisch. Server signiert mit privatem Schlüssel, jeder kann mit dem öffentlichen Schlüssel verifizieren. Perfekt für Multi-Service-Architekturen.
In Microservices-Architekturen ist RS256 der bessere Standard: der Auth-Server kennt den privaten Schlüssel und stellt Tokens aus, alle anderen Services kennen nur den öffentlichen Schlüssel – sie verifizieren, aber können nie selbst Tokens fälschen.
7) Der Login-Flow mit JWT
So sieht ein typischer Ablauf aus – Login, Token holen, mehrere geschützte Aufrufe machen. Beachte, dass die User-Datenbank nur einmal beim Login angefasst wird:
8) JWT vs. klassische Sessions
Vor JWT gab es Sitzungen mit Server-seitigem Zustand. Bei JWT liegt der Zustand im Token, also beim Client. Vgl. K11 Session-Management:
9) Sicherheits-Fallstricke
JWT ist mächtig, hat aber typische Anti-Patterns. Diese Punkte sind in IHK-Klausuren wie im Berufsalltag wichtig:
alg: none. Server muss das explizit ablehnen, sonst lassen sich Tokens fälschen."secret123" ist brute-force-bar in Minuten. Mindestens 32 random Bytes!Authorization-Header senden.{"alg":"none"}-Header und sprangen über die Signatur-Prüfung. Heute filtern alle ernsthaften Libraries das raus – aber nie blind vertrauen, Konfiguration immer explizit setzen: „nur RS256 akzeptieren".10) Refresh-Tokens: das Lebensdauer-Problem lösen
Kurze Token-Lebensdauer ist sicher (bei Diebstahl wenig Schaden), aber nervig (alle 15 Minuten neu einloggen). Lange Lebensdauer ist bequem, aber riskant. Die elegante Lösung: Access Token + Refresh Token.
- Access Token (JWT): kurze Lebensdauer (z.B. 15 Minuten). Wird bei jedem API-Aufruf mitgesendet.
- Refresh Token (oft kein JWT, sondern eine zufällige ID): lange Lebensdauer (z.B. 30 Tage). Nur einmal pro Verlängerung benutzt – um einen neuen Access Token zu holen. Beim Server gespeichert, daher widerrufbar.
Läuft der Access Token ab (401 vom Server), schickt der Client den Refresh Token an einen speziellen Endpunkt (POST /auth/refresh). Der Server prüft, ob er noch gültig ist (Datenbank-Lookup), und gibt einen neuen Access Token aus. Beste aus beiden Welten: kurze AT-Lebensdauer + Möglichkeit zum sofortigen Revoke.
11) JWT in der Praxis
Für IHK-Klausuren wichtig zu wissen, dass es ausgereifte JWT-Libraries für jede Sprache gibt: jsonwebtoken (Node.js), PyJWT (Python), jjwt (Java), System.IdentityModel.Tokens.Jwt (.NET). Selbst implementieren ist eine schlechte Idee – zu viele Sicherheits-Fallen.
Praxis-Tipp: jwt.io ist die offizielle Spielwiese, wo du Tokens dekodieren und manipulieren kannst. In jedem JWT-Projekt landet sie früher oder später im Browser-Tab.
Zusammenfassung
Ein JWT besteht aus drei punktgetrennten, Base64URL-kodierten Teilen: Header (Algorithmus), Payload (Claims wie sub, exp, role) und Signatur. Header und Payload sind nur kodiert, nicht verschlüsselt – jeder kann sie lesen. Die Signatur schützt vor Manipulation, berechnet mit HS256 (symmetrisch, ein geteiltes Secret) oder RS256 (asymmetrisch, ideal für Microservices). Im Request: Authorization: Bearer eyJ.... Vorteil gegenüber Sessions: stateless – der Server prüft nur die Signatur, kein DB-Zugriff nötig. Nachteil: Revocation schwer; Lösung sind Refresh Tokens (kurzlebiger Access Token + langlebiger Refresh Token). Klausur-Fokus: die drei Teile, Standard-Claims (sub/exp/iss), HS256 vs. RS256, Stateless-Eigenschaft. Anti-Patterns: sensitive Daten im Payload, fehlender exp-Claim, Algorithmus „none" zulassen, Token in URL/localStorage, schwache Secrets. Nächste Lektion: OAuth2 und OpenID Connect – das System hinter „Mit Google anmelden", das auf JWT aufbaut.