JWT (JSON Web Token) ist ein offener Standard, der von der IETF in RFC 7519 definiert wurde (RFC 7515 beschreibt die JWS-Signaturform, RFC 7516 beschreibt JWE-Verschlüsselung, RFC 7517 definiert JWK-Schlüssel) zur sicheren Übertragung 'behaupteter' Benutzerinformationen zwischen HTTP-Anfragen, OIDC-Flows und Microservice-Aufrufen. Eine Standard-JWT-Zeichenkette besteht aus drei Base64URL-kodierten Segmenten: Header (Algorithmus und Typ), Payload (Claims, die Benutzerdaten) und Signature (eine schlüsselbasierte Signatur über die ersten beiden). Die drei Segmente werden durch einen literalen Punkt `.` verbunden, z.B. `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.
**JWT ist keine Verschlüsselung.** Dies ist das häufigste Missverständnis. Die Payload ist standardmäßig Klartext — jeder kann sie mit Base64URL decodieren und den Inhalt lesen. JWT bietet **Manipulationserkennung**, nicht Vertraulichkeit: der Server signiert Header.Payload mit dem gemeinsamen Schlüssel erneut und vergleicht mit der Signature des Tokens. Wenn sie übereinstimmen, wurde das Token während der Übertragung nicht verändert. Dies ist die Metapher des 'Zugtickets mit Anti-Fälschungs-Stempel': dem Prüfer ist es wichtig, ob das Ticket echt ist, nicht ob der QR-Code unlesbar ist.
JWT teilt die Verantwortlichkeiten klar über 13 Algorithmen auf. **HMAC-Familie** (HS256/HS384/HS512) verwendet einen symmetrischen Schlüssel sowohl zum Signieren als auch zum Verifizieren, schnell und einfach, geeignet für einen einzelnen Dienst oder einen vertrauenswürdigen Cluster; das Secret muss mindestens die Digest-Länge haben (z.B. ≥ 32 Bytes für HS256). **RSA-Familie** (RS256/RS384/RS512) verwendet RSASSA-PKCS1-v1_5, das häufigste asymmetrische Schema — Unterzeichner halten den privaten Schlüssel, Verifizierer halten den öffentlichen Schlüssel. **RSA-PSS-Familie** (PS256/PS384/PS512) verwendet das neuere RSA-PSS-Padding mit stärkeren Sicherheitsgarantien, bevorzugt von AWS SigV4 und modernen OIDC-Identitätsanbietern. **ECDSA-Familie** (ES256/ES384/ES512) verwendet elliptische Kurven (P-256/P-384/P-521 jeweils) mit kürzeren Signaturen und besserer Leistung. **EdDSA** (hauptsächlich Ed25519) ist extrem schnell und deterministisch (gleiche Nachricht + gleicher Schlüssel = gleiche Signatur jedes Mal) und ist der empfohlene Algorithmus in OAuth 2.1 und neuen Protokollen.
Sicherheit ist der Punkt, an dem JWT in der Produktion scheitert. Das OWASP JWT Cheat Sheet nennt mindestens vier harte Regeln: (1) niemals Passwörter, nationale IDs, Kartennummern oder API-Schlüssel als Klartext in die Payload legen; (2) der Server darf **niemals dem alg-Feld** vertrauen, das im Token-Header deklariert ist — er muss mit einem hartcodierten Algorithmus verifizieren, sonst umgeht ein Angreifer, der den Header auf `alg: none` umschreibt, alles (dies ist die Wurzel historischer CVEs wie CVE-2015-9235); (3) HMAC-Secrets müssen zufällig und mindestens 32 Bytes lang sein, niemals kurze Zeichenketten; (4) Verifizierung ist mehr als Signaturprüfungen — Sie müssen auch `exp` (Ablauf), `nbf` (nicht vor), `iss` (Aussteller) und `aud` (Zielgruppe) validieren. Dieses Tool hebt jeden dieser Claims in der UI hervor, sodass Sie auf einen Blick erkennen können, ob ein Fehler ein Signaturproblem, ein Timing-Problem oder ein Claims-Problem ist.
JWT ist kein Ersatz für Sessions. Sessions speichern den Benutzerstatus auf dem Server (Redis oder einer Datenbank); JWT packt den Status in das Token. Microservice-Architekturen, zustandslose APIs, mobile Clients und CORS-lastige Setups profitieren von JWT; traditionelle Unternehmenssysteme und Flows, die sofortige Widerrufung erfordern (z.B. 'diesen Benutzer jetzt rauswerfen'), werden immer noch besser von Sessions bedient. Dieses Tool deckt sowohl reines JWT-Debugging als auch die Token-Analyse / Signatur-Verifizierung / Payload-Bearbeitungsschritte einer Session-zu-JWT-Migration ab.