JWT Decoder & Encoder – JSON Web Token Tool

Inhaltsverzeichnis

             Schnellübersicht
            JWT Decoder: Header, Payload und Signatur dekodieren
Signatur-Verify: HMAC-Signatur prüfen (HS256/384/512)
JWT Encoder: Eigene Tokens mit Secret erstellen
Claim-Analyse: exp, iat, nbf, iss, aud interpretieren
Sicherheitscheck: Schwachstellen automatisch erkennen
Theorie: Über JWT, Claims und Signatur
Geschichte: Von Cookies zu JWT
FAQ: Häufige Fragen zu JWT

        

1. JWT Tool

Wähle einen Modus: Token dekodieren, Signatur prüfen oder neue Tokens erstellen.

JWT Token Format: header.payload.signature (Base64URL-kodiert)

2. Aufbau eines JWT

Ein JWT besteht aus drei Base64URL-kodierten Teilen, getrennt durch Punkte.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Teil	Kodierung	Inhalt	Zweck
Header	Base64URL	{"alg": "HS256", "typ": "JWT"}	Algorithmus & Token-Typ
Payload	Base64URL	{"sub": "...", "name": "...", "iat": ...}	Claims (Nutzdaten)
Signature	HMAC / RSA	HMACSHA256(header.payload, secret)	Integrität & Authentizität

Base64URL ≠ Verschlüsselung

JWT-Payload ist Base64URL-kodiert – nicht verschlüsselt!
Jeder kann Header und Payload dekodieren (z.B. mit diesem Tool).
Nur die Signatur schützt vor Manipulation.
Niemals sensible Daten (Passwörter, Kreditkarten) ins JWT-Payload!
Für Vertraulichkeit: JWE (JSON Web Encryption) verwenden.

3. Theorie – JSON Web Tokens

Verstehe, wie JWT funktioniert und warum es überall genutzt wird.

Was ist ein JWT?

JSON Web Token ist ein kompakter, URL-sicherer Standard (RFC 7519) für die Übertragung von Claims zwischen Parteien:

Stateless: Server speichert keine Session
Selbstenthaltend: Alle Infos im Token
Signiert: Schutz vor Manipulation
Kompakt: Passt in HTTP-Header

Authorization: Bearer eyJhbGci...

Warum JWT?

Vorteile gegenüber klassischen Sessions:

Skalierbar: Keine Session-Speicherung nötig
Cross-Domain: Funktioniert über Domains hinweg
Microservices: Ein Token für alle Services
Mobile: Ideal für mobile Apps
Standard: In OAuth 2.0 und OpenID Connect

JWT ersetzt Session-Cookies in SPA/APIs

Standard-Claims

RFC 7519 definiert 7 Standard-Claims:

iss: Issuer (Aussteller)
sub: Subject (Betreff/Nutzer)
aud: Audience (Empfänger)
exp: Expiration Time
nbf: Not Before
iat: Issued At
jti: JWT ID (eindeutig)

exp: 1516239022 = 18.01.2018, 04:10:22 UTC

Best Practices

Niemals sensibel: Keine Passwörter/Credit-Cards im Payload
Kurze Laufzeit: exp max. 15-60 Min
HTTPS: Nur über TLS übertragen
HTTPS-Only-Cookies: Oder Authorization-Header
Signatur prüfen: Immer serverseitig verifizieren
Algorithmus fixieren: Nicht vom Token vertrauen
Refresh-Tokens: Für langlebige Sessions
Blacklist: Bei Logout (JWT ist stateless)

HS256 für Monolithen, RS256 für Microservices

Häufige JWT-Sicherheitsfehler

alg: none: Server akzeptiert unsignierte Tokens (kritisch!)
HS/RS-Verwechslung: Öffentlicher Schlüssel als HMAC-Secret
Fehlende exp-Prüfung: Abgelaufene Tokens akzeptiert
Schwacher Secret: "secret", "password", "1234"
Kid-Injection: Angreifer kontrolliert Key-ID
JWT im localStorage: XSS-anfällig (besser: httpOnly-Cookie)

4. Geschichte der JWT

Von Session-Cookies zu JSON Web Tokens.

1994

HTTP-Cookies

Netscape führt HTTP-Cookies ein (RFC 2109). Sessions werden serverseitig gespeichert – Standard für Web-Anwendungen bis heute.

2006

RFC 7515 – JWS

JSON Web Signature wird definiert. Grundlage für JWT: signierte JSON-Daten.

2011

Erste JWT-Drafts

Die IETF-Arbeitsgruppe OAuth veröffentlicht erste JWT-Entwürfe. Ziel: signierte Tokens für OAuth 2.0.

2014

RFC 7519 – JWT

JSON Web Token wird offiziell standardisiert. Die 7 Standard-Claims (iss, sub, aud, exp, nbf, iat, jti) werden definiert.

2015

JWT-Sicherheitslücken

Critical Vulnerabilities werden entdeckt: `alg: none`, HS/RS-Verwechslung, `kid`-Injection. Bibliotheken werden aktualisiert.

2016

JWT in OAuth 2.0

OpenID Connect nutzt JWT für ID-Tokens. JWT wird zum De-facto-Standard für Auth in Microservices und SPAs.

2019

JWE & JWS erweitert

JSON Web Encryption (JWE) gewinnt an Bedeutung. Verschlüsselte JWTs für sensible Daten.

Heute

JWT überall

JWT ist Standard in OAuth 2.0, OpenID Connect, Kubernetes, AWS Cognito, Auth0 und nahezu allen modernen Auth-Systemen.

5. FAQ – Häufige Fragen

Häufige Fragen zu JWT

Was ist ein JWT und wie funktioniert es?

JWT (JSON Web Token) ist ein signiertes Token, das Claims (Nutzdaten) enthält:

Header: Algorithmus und Typ (Base64URL)
Payload: Claims wie sub, name, exp (Base64URL)
Signatur: HMAC oder RSA-Signatur

Ablauf:

1. Login: Nutzer sendet Credentials an Server
2. Server prüft: Credentials gegen Datenbank
3. JWT erstellen: Server signiert Token mit Secret
4. Token senden: Client speichert Token (Cookie/localStorage)
5. Bei jeder Anfrage: Client sendet Token im Header
6. Server prüft Signatur: Ohne Datenbankzugriff

Ist JWT sicher?

Ja, wenn richtig implementiert! JWT selbst ist sicher, aber Implementierungsfehler sind häufig:

Typische Fehler:

alg: none: Server akzeptiert unsignierte Tokens
HS/RS-Verwechslung: Public Key als HMAC-Secret
Schwacher Secret: "secret" oder "1234"
Keine exp-Prüfung: Abgelaufene Tokens akzeptiert
JWT im localStorage: XSS-anfällig

Sicher umsetzen:

Algorithmus fixieren: Server gibt HS256 oder RS256 vor
Starkes Secret: Mindestens 32 Zeichen
exp prüfen: Abgelaufene Tokens ablehnen
httpOnly-Cookie: Nicht localStorage
HTTPS: Immer verschlüsselt übertragen

Wo sollte ich JWT speichern?

Drei Optionen mit unterschiedlichen Trade-offs:

Speicherort	Vorteile	Nachteile
httpOnly-Cookie	XSS-sicher, automatisch gesendet	CSRF-anfällig (mit CSRF-Token lösen)
localStorage	Einfach, JS-Zugriff	XSS-anfällig!
Memory (Variable)	Sicher gegen XSS	Verloren bei Page-Reload

Empfehlung:

Beste Wahl: httpOnly-Cookie mit SameSite=Strict + CSRF-Token
Zweite Wahl: Memory + Refresh-Token in httpOnly-Cookie
Nicht nutzen: localStorage (außer bei strikter CSP)

Was ist der Unterschied zwischen HS256 und RS256?

Merkmal	HS256 (HMAC)	RS256 (RSA)
Typ	Symmetrisch	Asymmetrisch
Schlüssel	1 Secret	Private + Public Key
Signieren	Mit Secret	Mit Private Key
Verifizieren	Mit gleichem Secret	Mit Public Key
Verteilung	Secret muss geteilt werden	Public Key frei verteilbar
Geschwindigkeit	Schneller	Langsamer
Einsatz	Monolithen	Microservices, OIDC

Faustregel:

HS256: Ein Server signiert und verifiziert
RS256: Ein Auth-Server signiert, viele Services verifizieren

Wichtig: Bei RS256 können Services mit dem Public Key verifizieren – der Private Key bleibt nur beim Auth-Server!

Wie logge ich Nutzer mit JWT aus?

Problem: JWT ist stateless – der Server weiß nicht, welche Tokens noch gültig sind.

Lösungen:

Client-seitig: Token löschen (aber Token bleibt gültig!)
Kurze Laufzeit: exp 15-60 Min – Token läuft bald ab
Blacklist: Server speichert widerrufene jti-Werte
Refresh-Tokens: Zugriff über Refresh widerrufen
Token-Version: Nutzer hat "tokenVersion" – bei Logout erhöhen

Empfehlung: Kurzlebige Access-Tokens (15 Min) + langlebige Refresh-Tokens (7 Tage). Bei Logout Refresh-Token widerrufen.

Kann ich JWT für sensible Daten nutzen?

Nicht direkt – JWT ist nur signiert, nicht verschlüsselt!

Warum nicht:

Base64URL ist keine Verschlüsselung
Jeder kann Payload dekodieren (z.B. jwt.io)
Man-in-the-Middle kann Payload lesen (ohne HTTPS)
Auch Browser-Entwickler-Tools zeigen Payload

Lösungen:

Nicht ins JWT: Passwörter, Kreditkarten, PII
Server-Session: Sensible Daten serverseitig speichern
JWE (JSON Web Encryption): Verschlüsselte JWTs
HTTPS: Mindestens Transportverschlüsselung

Faustregel: JWT = "Public Information mit Signatur". Niemals Geheimnisse!

Wie lang sollte die JWT-Laufzeit sein?

Empfehlungen nach Anwendungstyp:

Anwendung	Access Token	Refresh Token
Banking/Finanzen	5 Min	1 Tag
Unternehmens-Apps	15-30 Min	7 Tage
Consumer-Apps	60 Min	30 Tage
IoT/M2M	24 Std	90 Tage

Faustregel:

Kurz: Access-Token so kurz wie möglich
Balance: Nutzer-Comfort vs. Sicherheit
Refresh: Refresh-Token langlebig, aber widerrufbar
Rotation: Refresh-Token bei jedem Gebrauch erneuern

Was ist der Unterschied zwischen JWT und Session-Cookies?

Merkmal	Session-Cookie	JWT
Speicherung	Server (Session-Store)	Client (Token)
Skalierung	Session-Store nötig	Stateless
Größe	Klein (Session-ID)	Größer (Header+Payload+Signatur)
Widerruf	Einfach (Session löschen)	Schwierig (Blacklist)
Cross-Domain	Schwierig	Einfach
Microservices	Session-Store nötig	Ideal
Mobile	Cookies unüblich	Ideal

Wann was?

Session-Cookies: Monolith, traditionelle Web-App
JWT: SPA, Mobile App, Microservices, API

Hybrid: Viele Systeme nutzen beides – Session für Web, JWT für API.

Zusammenfassung

Die wichtigsten Punkte

JWT: JSON Web Token (RFC 7519)
Aufbau: header.payload.signature (Base64URL)
Nicht verschlüsselt: Nur signiert – jeder kann Payload lesen
Standard-Claims: iss, sub, aud, exp, nbf, iat, jti
Algorithmen: HS256 (symmetrisch), RS256 (asymmetrisch)
Stateless: Server speichert keine Sessions
Logout schwierig: Blacklist oder kurze Laufzeit
Sicherheit: Algorithmus fixieren, exp prüfen, HTTPS
Speicherort: httpOnly-Cookie (nicht localStorage)
Unser Tool: Decode + Verify + Encode lokal

Weitere Sicherheits-Tools

Bcrypt Tool

Echte bcrypt-Hashes erstellen und verifizieren.

Zum Tool

Hash Generator

MD5, SHA-1, SHA-256 und SHA-512 für Text und Dateien.

Zum Tool

Key Strength Comparison

RSA, ECC, AES und DH Schlüsselstärken nach NIST vergleichen.

Zum Tool

File Integrity Checker

Datei-Integrität mit MD5, SHA-1, SHA-256 und SHA-512 prüfen.

Zum Tool