JWT-Analysetool
JSON Web Token dekodieren und validieren, Header, Payload, Signature prüfen
Beispiel JWT
Was ist JWT?
JWT (JSON Web Token) ist ein offener Standard (RFC 7519) zur sicheren Übertragung von Informationen zwischen Parteien. JWT besteht aus drei durch Punkte getrennten Teilen: Header (enthält Tokentyp und Signatur-Algorithmus), Payload (enthält Claims-Daten) und Signature (überprüft die Token-Integrität). JWT wird häufig für Authentifizierung und Informationsaustausch verwendet. Beim Arbeiten mit JWTs ist wichtig, zwischen Dekodieren und Verifizieren zu unterscheiden. Header und Payload sind nur Base64URL-kodiert und können gelesen werden, ohne dass die Signatur gültig ist. Vertrauen entsteht erst durch serverseitige Prüfung von Signatur, Algorithmus, Ablaufzeit, Aussteller und Zielgruppe. Sensible Daten gehören nicht unverschlüsselt in den Payload, weil jeder Besitzer des Tokens sie lesen kann.
Bedienungsanleitung
So wird es verwendet
- Fügen Sie ein JWT in das Eingabefeld ein – das Tool analysiert automatisch und zeigt Header und Payload an.
- Klicken Sie auf farbige Tags, um den entsprechenden Base64-kodierten Teil zu kopieren.
- Geben Sie im Signaturprüfbereich das Geheimnis ein, um die Signatur zu verifizieren (unterstützt HS256/HS384/HS512).
- Im Schlüsselinformationsbereich werden decodierte Werte für gängige Claims angezeigt, der Ablaufstatus ist farblich gekennzeichnet.
Sicherheitstipps
- Dieses Tool läuft lokal in Ihrem Browser – das Token wird niemals an einen Server gesendet.
- JWT kodiert und signiert Daten nur, es verschlüsselt sie nicht – jeder kann den Inhalt decodieren und einsehen.
- Speichern Sie keine sensiblen Daten im JWT (z. B. Passwörter, Kreditkartennummern).
- Verwenden Sie in Produktionsumgebungen immer HTTPS für die Übertragung von JWT.
Anwendungsfälle
Technisches Prinzip
JWT (JSON Web Token, RFC 7519) besteht aus drei Teilen — Header.Payload.Signature — verbunden durch den englischen Punkt '.'. Header: Beschreibt den Tokentyp und den Signatur-Algorithmus, z. B. {"alg":"HS256","typ":"JWT"}. alg bestimmt, wie die Signatur berechnet wird; gängige Algorithmen sind HS256 (HMAC-SHA256), RS256 (RSA-SHA256), ES256 (ECDSA-SHA256) und none (keine Signatur — in der Produktion verboten). Payload: auch Claims genannt, eine Sammlung von JSON-Feldern. RFC 7519 definiert 7 standardregistrierte Claims: iss (Aussteller), sub (Subject, meist eine Benutzer-ID), aud (Zielgruppe), exp (Ablaufzeit), nbf (nicht vor), iat (Ausgabezeitpunkt) und jti (eindeutige ID). Entwickler können darüber hinaus beliebige private Felder hinzufügen, wie userId, role, tenant. Signatur: Header und Payload werden Base64URL-kodiert, mit einem Punkt verbunden und dann mit dem durch alg angegebenen Algorithmus und einem Schlüssel signiert. HS256 verwendet HMAC-SHA256(secret, header_b64 + '.' + payload_b64); RS256 verwendet einen RSA-Private-Key. Der Empfänger berechnet die Signatur auf die gleiche Weise neu und prüft, ob beide übereinstimmen. Base64URL vs. Standard-Base64: '+' wird zu '-', '/' wird zu '_', und das abschließende '='-Padding wird weggelassen, sodass das Ergebnis in URL-Pfaden und Query-Strings verwendet werden kann, ohne Prozentkodierung auszulösen. Beachten Sie, dass Base64URL nur eine Kodierung ist — sie bietet keine Verschlüsselung oder Sicherheit, und jeder kann die Payload dekodieren und lesen. Sicherheitsgrenze: JWT garantiert nur 'nicht manipuliert', nicht 'Inhalt ist vertraulich'. Ein häufiger Fehler ist es, Telefonnummern, Personalausweisnummern oder Passwort-Hashes in die Payload zu packen, wo jeder sie sehen kann.
- Dreiteilige Struktur: Header.Payload.Signature, jeweils Base64URL-kodiert; die Signatur ist HMAC(secret, header_b64 + '.' + payload_b64) oder RSA(privateKey, gleicher Input).
- Base64URL tauscht '+' → '-', '/' → '_' und lässt das abschließende '='-Padding weg, sodass das kodierte Ergebnis direkt in einer URL stehen kann (keine Prozentkodierung ausgelöst).
- Dieses Tool verifiziert lokal nur HMAC-Signaturen (HS256/HS384/HS512). Asymmetrische Verfahren wie RS256 oder ES256 erfordern den öffentlichen Schlüssel vom JWKS-Endpunkt des Ausstellers, sodass die Signaturprüfung auf einem Server mit Zugriff auf den Public Key erfolgen muss — die Seite kann Header und Payload dekodieren, aber nicht verifizieren.
- Standard-Claims: iss (Aussteller), sub (Subject), aud (Zielgruppe), exp (Ablaufzeit als Unix-Timestamp in Sekunden), nbf (nicht vor), iat (Ausgabezeitpunkt), jti (JWT-ID, verhindert Replay).
- alg=none-Angriff: Das alg-Feld muss strikt validiert werden und der none-Algorithmus muss abgelehnt werden, sonst kann ein Angreifer beliebige Tokens fälschen; Algorithmus-Substitutionsangriffe (Verifizierung eines HS256-Tokens mit dem Public Key als Secret) müssen ebenfalls verhindert werden.
- JWT ist nicht verschlüsselt: Die Payload ist als plaintext Base64URL-kodiert, nicht verschlüsselt; für vertrauliche Inhalte wird JWE (JSON Web Encryption) verwendet, in der Praxis ist jedoch das gängige Muster, sensible Daten auf dem Backend zu halten und über das sub-Feld zu referenzieren.
Beispiele
Standard HS256-Token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzA1MzEyODAwLCJleHAiOjE3MDUzMTY0MDB9.znHapMygT8K8YZN4K8zM1sV3bKlQ5pY3xE2gR4wN1vM
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"1234567890","name":"Jane Doe","iat":1705312800,"exp":1705316400}
RFC: RFC 7519 Abschnitt 3 definiert die Registered Claim Names (sub, iat, exp)Abgelaufener Token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsImV4cCI6MTYwMDAwMDAwMH0.OxQ0fUKW0z4mK0xJ4vF0uF7eZB9wK3yF8pL2nQ6tX1k
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-123","exp":1600000000}
Status: abgelaufen (exp < jetzt)
Hinweis: der exp-Claim verwendet NumericDate (Sekunden seit der Unix-Epoche gemäß RFC 7519 Abschnitt 2)User-Info-Token mit benutzerdefinierten Claims
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQ1NiIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsInRlbmFudCI6ImFjbWUiLCJpYXQiOjE3MDUzMTI4MDAsImV4cCI6MTcwNTMxNjQwMCwiYXVkIjoiYXBpLmV4YW1wbGUuY29tIn0.7Hk2L9oP3qR1mN4vK8xJ2wE5yT6sB0fA9cZ1dG3hI4U
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-456","name":"Alice","role":"admin","tenant":"acme","iat":1705312800,"exp":1705316400,"aud":"api.example.com"}
Hinweis: role, tenant sind private Claims - nicht in RFC 7519 definiertSicherheits-Checkliste für die JWT-Implementierung
1. Niemals Geheimnisse im Payload speichern - JWT ist kodiert, nicht verschlüsselt
2. Starke Schlüssel für HS256 verwenden (>= 256 Bit / 32 Zeichen zufällig)
3. RS256/ES256 für Public-Key-Verifizierung in Multi-Service-Systemen bevorzugen
4. alg-Header validieren - 'none' oder unerwartete Algorithmen ablehnen
5. exp-, nbf-, iat-Zeitstempel prüfen, bevor dem Token vertraut wird
6. Sicherstellen, dass aud zu Ihrem Dienst passt, um Token-Wiederverwendung zwischen Anwendungen zu verhindern
7. In HttpOnly-Cookies speichern, nicht im localStorage (XSS-Schutz)
RFC: RFC 8725 (JWT Best Practices) deckt diese Sicherheitsaspekte abFAQ
Aus welchen drei Teilen besteht ein JWT?
Header, Payload und Signatur, getrennt durch Punkte. Der Header gibt den Signaturalgorithmus und Token-Typ an. Der Payload trägt Claims wie sub, iss, aud, iat, exp und beliebige Zusatzdaten. Mit der Signatur kann der Verifier prüfen, dass das Token nicht manipuliert wurde. Header und Payload sind Base64URL-codiertes JSON – sie sind signiert, nicht verschlüsselt.
Ist ein JWT verschlüsselt?
Nein – ein normales JWT im JWS-Format ist signiert, aber nicht verschlüsselt. Wer es abfängt, kann Header und Payload Base64URL-decodieren und alle Claims lesen, einschließlich Nutzer-IDs, E-Mails und Rollen. Behandle JWT-Inhalte als öffentlich; lege niemals Passwörter oder Geheimnisse in den Payload. JWE (verschlüsseltes JWT) gibt es, ist aber deutlich seltener.
Was bedeutet jeder Standard-Claim?
iss = Issuer; sub = Subject (oft die Nutzer-ID); aud = Audience (gewünschter Empfänger); exp = Ablauf (Unix-Sekunden); nbf = not before; iat = issued at; jti = eindeutige Token-ID für Sperrlisten. Sie sind in RFC 7519 definiert. Custom-Claims kannst du frei ergänzen – setze ein Hersteller-Präfix, um Kollisionen zu vermeiden.
Wie verifiziere ich ein JWT?
Lies den alg-Header, nutze den passenden Schlüssel (HS256 = gemeinsames Geheimnis, RS256/ES256 = öffentlicher Schlüssel vom JWKS-Endpoint des Ausstellers), berechne die Signatur über den codierten header.payload neu und vergleiche. Prüfe danach exp, nbf, iss und aud. Lehne das Token ab, wenn alg „none“ ist oder von dem abweicht, was dein Server erwartet. Dieses Tool verifiziert lokal nur HS256/HS384/HS512-Signaturen (geteiltes Secret); die Prüfung von RS256/ES256 muss auf einem Server mit dem öffentlichen Schlüssel laufen.
Findet die Verifikation in meinem Browser statt?
Ja. Die Seite parst das JWT lokal und verifiziert HS256/HS384/HS512-Signaturen mit HMAC, das per JavaScript im Browser läuft. Der Token erreicht unseren Server nicht, aber denk daran: ein JWT ist ohnehin dafür gedacht, in URLs und Headern zu reisen — jedes kopierte JWT kann in Logs auftauchen.
Warum ist alg=none gefährlich?
RFC 7519 erlaubt alg=none für unsignierte Tokens. Ein anfälliger Verifier akzeptiert ein solches Token möglicherweise trotz fehlender Signatur, sodass ein Angreifer beliebige Payloads fälschen kann. Moderne Bibliotheken lehnen alg=none standardmäßig ab; wenn du selbst einen Verifier schreibst, hard-code den erwarteten Algorithmus, statt dem Header zu vertrauen.
Wie groß darf ein JWT werden?
Es gibt keine Protokollgrenze, doch JWTs landen meist in HTTP-Headern (Authorization: Bearer ...) und viele Server begrenzen Header auf rund 8 KB. Jeder zusätzliche Claim macht jede Anfrage größer. Brauchst du viel Session-State, nutze eine Server-Session und packe nur ein kleines Referenz-Token ins JWT.