> dekodieren | untersuchen | verifizieren <
// JSON Web Tokens (JWT) sofort dekodieren und untersuchen
Lokale Verarbeitung
100% clientseitige JWT-Dekodierung. Ihre Tokens verlassen niemals Ihren Browser.
Auto-Dekodierung
JWT-Tokens werden beim Einfügen oder Tippen automatisch dekodiert.
Vollständige Token-Inspektion
Header, Payload und Signatur anzeigen. Algorithmus und Ablauf prüfen.
// ÜBER JWT-DEKODIERUNG
JWT-Struktur:
Ein JSON Web Token (JWT) besteht aus drei Base64URL-kodierten Teilen, getrennt durch Punkte: Header.Payload.Signatur. Der Header gibt den Algorithmus und den Tokentyp an. Der Payload enthält Claims (Daten). Die Signatur überprüft die Integrität des Tokens.
Beispiel:
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.signature → {"alg":"HS256"} + {"sub":"1234"}
Häufige Anwendungsfälle:
- >Debugging von Authentifizierungstokens in Webanwendungen
- >Inspektion von OAuth 2.0 und OpenID Connect Tokens
- >Überprüfung von Token-Ablauf und Claims
- >Verständnis der JWT-Struktur gemäß RFC 7519
- >Prüfung der Base64URL-Kodierungsintegrität
>> häufig gestellte Fragen
F: Was ist ein JSON Web Token (JWT)?
A: JWT (JSON Web Token) ist ein offener Standard (RFC 7519) für die sichere Übertragung von Informationen zwischen Parteien als JSON-Objekt. Es ist kompakt, URL-sicher und wird häufig für Authentifizierung verwendet.
F: Was sind die drei Teile eines JWT?
A: Ein JWT besteht aus drei Teilen, getrennt durch Punkte: dem Header (Algorithmus und Typ), dem Payload (Claims und Daten) und der Signatur (Verifikationshash). Jeder Teil ist Base64URL-kodiert.
F: Kann ein JWT ohne den geheimen Schlüssel dekodiert werden?
A: Ja, Header und Payload eines JWT können von jedem dekodiert werden, da sie lediglich Base64URL-kodiert (nicht verschlüsselt) sind. Der geheime Schlüssel wird nur zur Verifizierung der Signatur benötigt.
F: Was ist der Unterschied zwischen JWT und sitzungsbasierter Authentifizierung?
A: Sitzungen speichern den Zustand auf dem Server mit einem Sitzungs-ID-Cookie. JWTs sind zustandslos — das Token selbst enthält alle nötigen Informationen. JWTs eignen sich besser für verteilte Systeme und APIs.
F: Wie funktioniert der JWT-Ablauf?
A: Der exp-Claim im JWT-Payload gibt die Ablaufzeit als Unix-Zeitstempel an. Nach dieser Zeit sollte das Token als ungültig betrachtet werden. Dieser Decoder prüft den exp-Claim und zeigt an, ob das Token noch gültig oder abgelaufen ist.
// Gängige JWT-Signaturalgorithmen
Der Header-Wert alg legt fest, wie die Signatur erzeugt wird. HS* nutzt ein gemeinsames Geheimnis, RS*, PS*, ES* und EdDSA nutzen Schlüsselpaare.
| alg | Algorithmus |
|---|---|
| HS256 | HMAC + SHA-256 |
| HS512 | HMAC + SHA-512 |
| RS256 | RSA PKCS#1 v1.5 + SHA-256 |
| PS256 | RSASSA-PSS + SHA-256 |
| ES256 | ECDSA P-256 + SHA-256 |
| EdDSA | Ed25519 |
// JWT im Code verifizieren
Dekodieren allein prüft nichts. Gib beim Verifizieren immer die erlaubten Algorithmen explizit an.
Node.js (jsonwebtoken) jwt.verify(token, secret, { algorithms: ['HS256'] })
Python (PyJWT) jwt.decode(token, key, algorithms=["HS256"])
PHP (firebase/php-jwt) JWT::decode($token, new Key($key, 'HS256'))
Go (golang-jwt) jwt.Parse(token, keyFunc, jwt.WithValidMethods([]string{"HS256"}))
Java (jjwt) Jwts.parser().verifyWith(key).build().parseSignedClaims(token)
>> Weitere Fragen
F: Was bedeuten die Standard-Claims iss, sub, aud, exp, nbf, iat und jti?
A: iss ist der Aussteller, sub das Subjekt (meist die Nutzer-ID), aud die vorgesehene Zielgruppe, exp der Ablaufzeitpunkt, nbf der früheste Gültigkeitszeitpunkt, iat der Ausstellungszeitpunkt und jti eine eindeutige Token-ID. Zeitangaben sind Unix-Sekunden.
F: Ist ein JWT verschlüsselt?
A: Ein normales signiertes JWT (JWS) ist nicht verschlüsselt, sondern nur Base64URL-kodiert: Jeder kann den Inhalt lesen. Die Signatur schützt nur vor Manipulation. Vertrauliche Daten gehören nicht hinein, oder man verwendet ein verschlüsseltes JWE.
F: Wie verifiziere ich die Signatur eines JWT?
A: Du benötigst den Schlüssel: das gemeinsame Geheimnis bei HS256 oder den öffentlichen Schlüssel bei RS256/ES256. Der Server berechnet die Signatur über Header.Payload neu und vergleicht sie. Dieser Decoder arbeitet im Browser und prüft die Signatur nicht für dich – nutze dafür eine geprüfte Bibliothek.
F: Welche typischen Sicherheitsfehler gibt es bei JWT?
A: Häufig sind: den alg-Wert aus dem Token ungeprüft übernehmen (insbesondere none), schwache HS256-Geheimnisse, fehlende Prüfung von exp, iss und aud, sensible Daten im Payload und das Speichern langlebiger Tokens im localStorage.