JWT Decoder

Was ist ein JWT?

Ein JSON Web Token (kurz JWT, gesprochen "jot") ist ein kompakt kodiertes, signiertes JSON-Objekt nach RFC 7519. Es transportiert Behauptungen (Claims) zwischen zwei Parteien, typischerweise zwischen einem Auth-Server und einer API. Der Server stellt das Token nach erfolgreicher Authentifizierung aus, der Client legt es bei jedem API-Call dem `Authorization: Bearer ...` Header bei.

JWTs bestehen aus drei base64url-kodierten Teilen, die mit Punkten getrennt sind. Sie sind nicht verschlüsselt, sondern lediglich signiert. Wer den Token in die Hand bekommt, kann den Inhalt lesen, weshalb in den Payload niemals Passwörter oder andere Geheimnisse gehören.

Der Vorteil gegenüber Server-Side-Sessions: ein JWT ist self-contained. Ein API-Server kann das Token validieren und Berechtigungen entnehmen, ohne den Auth-Server zu kontaktieren oder eine Session-Datenbank abzufragen. Das skaliert horizontal hervorragend, kostet dafür aber die Möglichkeit, einzelne Tokens vorzeitig zu widerrufen.

Header, Payload, Signature erklärt

Jeder JWT besteht aus drei Teilen, getrennt durch je einen Punkt:

• Header: kleines JSON-Objekt mit `alg` (Algorithmus, z. B. HS256, RS256, ES256) und `typ` (in der Regel "JWT"). Manchmal zusätzlich `kid` (Key-ID) als Hinweis, welcher Schlüssel zum Signieren verwendet wurde.
• Payload: JSON-Objekt mit den Claims. Standardisierte Felder sind `iss` (Issuer), `sub` (Subject), `aud` (Audience), `exp` (Expiration), `nbf` (Not Before), `iat` (Issued At) und `jti` (eindeutige Token-ID). Daneben sind beliebige eigene Felder erlaubt.
• Signature: über `base64url(header) + "." + base64url(payload)` mit dem konfigurierten Algorithmus berechnet. Sie schützt die Integrität: ohne Kenntnis des Schlüssels lässt sich der Inhalt nicht unbemerkt manipulieren.

Wichtig: base64url ist eine Kodierung, keine Verschlüsselung. Header und Payload sind für jeden Beobachter lesbar.

JWT vs. Session-Cookies

Beide Ansätze halten einen authentifizierten Zustand fest, gehen aber unterschiedlich vor:

• Session-Cookie: undurchsichtige ID, der Server schlägt darüber den vollständigen Zustand in der Session-Datenbank nach. Sofort widerrufbar, kostet aber pro Request einen Lookup.
• JWT: enthält den Zustand selbst, nur per Signatur gesichert. Kein Lookup, perfekt für Microservice-Architekturen, aber Tokens lassen sich vor Ablauf nur per Allow-/Deny-Liste widerrufen.
• Größe: JWTs sind häufig 300 bis 1500 Bytes groß. Session-IDs liegen meist um 32 Bytes. Bei vielen API-Calls summiert sich die JWT-Größe in der Bandbreite.
• Storage: Cookies (HttpOnly, Secure, SameSite) sind für die Browser-Welt der sicherere Speicherort. localStorage ist anfällig für XSS.

Faustregel: für reine Server-Apps Sessions, für API-Gateways und Mobile Backends JWTs, idealerweise mit kurzer Lifetime und Refresh-Token-Flow.

JWT-Sicherheit: Was tun bei `algorithm: none`?

JWTs haben in den letzten Jahren einige spektakuläre Bibliotheks-Bugs erlebt. Die wichtigsten Fallstricke:

• `alg: none`: einige Libraries akzeptierten Tokens ohne Signatur, wenn der Header so etwas behauptete. Lösung: niemals `none` zulassen, der erlaubte Algorithmus muss serverseitig fest verdrahtet sein.
• HS256/RS256-Confusion: ein Angreifer schickt ein mit dem RSA-Public-Key als HMAC-Secret signiertes Token, der Server prüft es als HS256 statt RS256, Treffer. Verteidigung: erlaubter `alg` ist serverseitig fix.
• `kid` Injection: das `kid`-Feld zeigt auf einen Schlüssel, kann aber, wenn unsanitized, zu Path-Traversal oder SQL-Injection führen. Behandle den Wert als untrusted Input.
• Schwache Secrets: HS256-Tokens mit "secret" oder "password" als Schlüssel sind in Sekunden brute-forcebar. Verwende mindestens 256 zufällige Bits, am besten von `crypto.getRandomValues()` bzw. `/dev/urandom`.
• Lange Lifetime: jeder ausgegebene JWT ist bis zum Ablauf gültig, auch wenn der Nutzer schon "ausgeloggt" hat. Kurze Lifetime (15 min) plus Refresh-Token oder eine Deny-Liste für sensible Endpunkte.

Die OWASP-Cheatsheet-Reihe sowie RFC 8725 (JWT Best Current Practices) sind Pflichtlektüre.

Wie validiere ich ein JWT?

Eine vollständige Validierung umfasst weit mehr als nur die Signatur. Reihenfolge im Server-Code:

• Header parsen, `alg` gegen die Allowlist prüfen (z. B. nur RS256 erlaubt).
• Signatur mit dem zur Issuer-Konfiguration passenden Schlüssel prüfen. Bei JWKS ggf. den `kid` zum Lookup verwenden, Werte vorher whitelisten.
• Standard-Claims prüfen: `iss` matcht den erwarteten Issuer, `aud` enthält die eigene Audience, `exp` ist in der Zukunft, `nbf` und `iat` sind in der Vergangenheit (mit kleiner Clock-Skew-Toleranz).
• Eigene Claims (Rollen, Tenant-ID, Scopes) gegen das Geschäfts-Modell validieren.
• Bei Bedarf Deny-Liste / Logout-Liste prüfen, falls vorzeitige Revocation gefordert ist.

Verlasse dich auf eine etablierte Library (jose, jjwt, jsonwebtoken etc.), nicht auf selbst geschriebenen Code. Kryptografie ist kein Bastelprojekt.

Auth-Backend bei KernelHost hosten

JWT-Issuer und Resource-Server brauchen ein zuverlässiges, latenzarmes Backend. KernelHost betreibt eigene VPS- und Dedicated-Server in Frankfurt FRA01 mit DDoS-Schutz, IPv4 + IPv6 sowie 1 Gbit/s Anbindung. Niedrige RTT zu europäischen Endkunden, faire Preise, kein Vendor-Lock-in. Firmensitz Wien (AT), Rechenzentrum Frankfurt (DE).

Häufige Fragen zu JWT