Häufige Fragen zu JWT

Ein JWT ist ein kompaktes, URL-sicheres Token-Format (RFC 7519) zur sicheren Übermittlung von Claims zwischen zwei Parteien. Es besteht aus drei base64url-kodierten Teilen: Header (Algorithmus), Payload (Claims wie User-ID, Berechtigungen, Ablaufzeit) und Signature (kryptographischer Integritätsbeweis). JWTs werden meist als Auth-Tokens in OAuth-2.0- und OpenID-Connect-Flows verwendet.

Beim jwtdecoder.de ja - die gesamte Dekodierung und Signaturprüfung läuft 100% im Browser über die Web Crypto API. Es wird nichts an einen Server gesendet, kein Logging, kein Tracking des Token-Inhalts. Trotzdem gilt: Produktions-Tokens mit echten User-Daten am besten nur auf vertrauenswürdigen Geräten dekodieren - physischer Geräte-Zugriff wäre eine eigene Angriffsfläche.

Registered Claims aus RFC 7519: iss (Issuer) identifiziert die ausstellende Instanz, sub (Subject) den Nutzer, aud (Audience) den Ziel-Service, exp (Expiration) den Ablaufzeitpunkt als Unix-Timestamp, iat (Issued At) den Ausstellungszeitpunkt, nbf (Not Before) den Gültigkeitsbeginn und jti (JWT ID) eine eindeutige Token-ID.

JWT ist stateless - der Server speichert keinen Session-State, weil alle Claims im Token signiert sind. Klassische Sessions speichern den State in einer Datenbank, der Cookie ist nur eine opake Session-ID. JWT lohnt sich bei Microservices und Mobile-Clients. Klassische Sessions bleiben besser für Monolithen, bei denen sofortiger Logout wichtig ist.

2015 entdeckt: mehrere JWT-Libraries akzeptierten Tokens mit Header alg="none" als gültig, weil sie den alg-Wert vertrauten. Angreifer konnte ein Token bauen, Signatur weglassen, alg auf none setzen - Server akzeptierte. Fix: Verifier MUSS einen erlaubten Algorithmus explizit erwarten (Whitelist), niemals nur dem Header-Wert vertrauen.

Access-Tokens: 5-15 Minuten. Refresh-Tokens: 7-30 Tage. Lange Lifetimes (mehrere Stunden bis Tage) sind ein Anti-Pattern, weil JWTs nicht ohne Weiteres revoziert werden können - der Server müsste eine Blacklist führen, was den Stateless-Vorteil eliminiert. Kurze Access-Tokens + Refresh-Token-Rotation ist die übliche Production-Antwort.

Empfehlung: httpOnly-Cookie mit SameSite=Strict (oder Lax) + zusätzlichem CSRF-Token. localStorage ist XSS-anfällig (jedes JavaScript der Origin kann es lesen), sessionStorage hat dasselbe Problem. httpOnly-Cookies sind XSS-sicher, dafür CSRF-relevant - daher die Kombination mit SameSite und CSRF-Token.

Nein - der Payload ist nur base64url-encoded, NICHT verschlüsselt. Jeder mit Token-Zugriff kann den Inhalt lesen, z.B. über jwtdecoder.de. Sensible Daten (Passwörter, Kreditkarten, persönliche Geheimnisse) gehören NIE in den Payload. Will man verschlüsseln, braucht man JWE statt JWS - aber TLS reicht für die meisten Use-Cases.

Dekodierung funktioniert mit jedem Algorithmus. Signaturprüfung: HMAC (HS256/384/512) mit Shared Secret, RSA (RS256/384/512) mit Public Key im PEM-Format, ECDSA (ES256/384/512) ebenfalls mit Public Key. Alle Verifikationen laufen über die Web Crypto API direkt im Browser.

HS256 (HMAC, symmetrisch): wenn ein einziger Service Tokens ausstellt UND verifiziert. Vorteil: schneller, kürzere Tokens. Nachteil: jeder Verifier kennt das Secret und könnte auch signieren. RS256 (RSA, asymmetrisch): wenn ein Issuer Tokens für viele unabhängige Verifier ausstellt. Verifier kennen nur den Public Key, können selber nicht signieren. Standard bei OAuth-Providern.

Beide sind asymmetrisch. RS256 nutzt RSA (typisch 2048-bit Keys), ES256 nutzt ECDSA über Curve P-256 (~256-bit Keys). ES256 erzeugt deutlich kürzere Signaturen (~64 byte vs ~256 byte bei RS256), ist auf Server-Seite schneller, Mobile/IoT-freundlicher. RS256 ist trotzdem verbreiteter, weil ältere und Enterprise-Systeme oft kein ECDSA unterstützen.

kid (Key ID) identifiziert, welcher Schlüssel zum Signieren verwendet wurde. Der Verifier sucht im JWKS-Endpoint des Issuers nach diesem kid und holt den passenden Public Key. Erlaubt Key-Rotation: Issuer kann mehrere Keys parallel haben, alte Tokens bleiben gültig bis Ablauf, neue Tokens werden mit neuem Key signiert.

Im JWT Decoder einfach das Token einfügen - der exp-Claim wird automatisch gegen die aktuelle Uhrzeit geprüft. Ist das Token abgelaufen, erscheint ein roter "Abgelaufen"-Badge. Selber prüfen: exp ist Unix-Timestamp (Sekunden seit Epoch), nicht Millisekunden. Empfehlung: ±30-60 Sekunden Clock-Skew tolerieren, weil Uhren zwischen Issuer und Verifier nie exakt synchron sind.

User loggt sich ein, bekommt Access-Token (5-15 min) + Refresh-Token (7-30 Tage). Beim Ablauf des Access-Tokens schickt der Client den Refresh-Token an /token-Endpoint, kriegt neues Access-Token + neuen Refresh-Token (Rotation). Vorteil: kompromittierte Access-Tokens sind nur kurz gefährlich. Refresh-Tokens werden bei Reuse-Detection (Token wird zweimal verwendet) sofort revoziert.

JWKS (JSON Web Key Set) ist ein JSON-Dokument mit den Public Keys eines Issuers, typisch unter /.well-known/jwks.json. Verifier ruft das JWKS einmal ab (mit Caching, typisch 1-24 h), liest das kid aus dem JWT-Header, sucht den passenden Key im JWKS und verifiziert damit die Signatur. Standard bei OAuth-Providern wie Google, Auth0, Keycloak.

Sechs typische Ursachen: 1) falscher Secret/Key beim Verifier, 2) Secret-Encoding-Mismatch (UTF-8 vs base64 vs hex), 3) alg-Mismatch (Token signiert mit HS256, Verifier erwartet RS256), 4) Token-Whitespace beim Kopieren mitkopiert, 5) ECDSA-Signatur-Format-Konflikt (JOSE raw vs DER), 6) Public Key passt nicht zum Private Key des Issuers.

Meistens Uhren-Drift zwischen Issuer und Verifier. Wenn der Verifier-Server 60 Sekunden vorgeht und exp-Lifetime 30 s ist, ist das Token "schon abgelaufen" beim Ankommen. Fix: NTP auf beiden Seiten, Clock-Skew-Toleranz beim Verifier konfigurieren (±60s ist üblich), exp-Lifetime ≥ 5 min wählen.