JWT Online dekodieren
JWT-Tokens im Browser dekodieren – keine Daten werden an einen Server gesendet.
Warum dieses Tool nutzen
JWT-Tokens sofort debuggen
100% privat
Die Dekodierung erfolgt in deinem Browser. Dein Token verlässt niemals dein Gerät.
Sofortige Verarbeitung
Echtzeit-Dekodierung während der Eingabe. Keine Buttons, kein Warten.
Formatiertes JSON
Header und Payload als lesbares JSON mit korrekter Syntaxhervorhebung.
Alle JWT-Typen unterstützt
Funktioniert mit HS256, RS256, ES256 und jedem Algorithmus im JOSE-Standard.
So funktioniert es
Drei Schritte, kein Aufwand
JWT-Token einfügen
Kopiere und füge ein beliebiges JWT in das Eingabefeld ein. Das Format besteht aus drei durch Punkte getrennten Teilen: Header.Payload.Signature.
Sofortige Dekodierung
Header und Payload werden aus Base64URL dekodiert und als formatiertes JSON angezeigt. Sieh den Algorithmustyp, Aussteller, Ablaufzeit und alle Claims.
Daten analysieren
Überprüfe jedes Payload-Feld: iss (Aussteller), sub (Betreff), exp (Ablaufzeit), iat (ausgestellt am), aud (Zielgruppe) und alle benutzerdefinierten Claims.
FAQ
Noch Fragen?
JWT (JSON Web Token) ist ein offener Standard (RFC 7519), der eine kompakte, in sich geschlossene Methode zur Übertragung von Informationen zwischen Parteien als JSON-Objekt definiert. Das Token ist digital signiert, was die Überprüfung seiner Echtheit ermöglicht. Es wird häufig für Authentifizierung und Autorisierung in REST-APIs und modernen Webanwendungen eingesetzt.
Wenn sich ein Nutzer anmeldet, erstellt der Server ein JWT, signiert es mit einem geheimen Schlüssel (HS256) oder privaten Schlüssel (RS256) und sendet es an den Client. Der Client speichert das Token (typischerweise im Arbeitsspeicher oder im localStorage) und sendet es mit jeder Anfrage als Authorization: Bearer Token. Der Server prüft die Token-Signatur ohne Datenbankabfrage, was JWT zu einem zustandslosen Authentifizierungsmechanismus macht, der in verteilten Systemen gut skaliert.
Ein JWT ist signiert, nicht verschlüsselt. Das bedeutet, jeder kann den Payload dekodieren und seinen Inhalt lesen – füge daher niemals Passwörter, Kreditkartendaten oder sensible Informationen in den Payload ein. Die Signatur garantiert die Integrität (niemand kann das Token verändern, ohne es ungültig zu machen), aber keine Vertraulichkeit. Wenn du den Inhalt verschlüsseln möchtest, verwende JWE (JSON Web Encryption).
Claims sind Aussagen über das Token-Subjekt. Registrierte Claims (RFC 7519) umfassen: iss (Aussteller), sub (Betreff), exp (Ablaufzeit als Unix-Timestamp), iat (ausgestellt am), aud (Zielgruppe), nbf (nicht vor) und jti (JWT-ID). Darüber hinaus kannst du beliebige benutzerdefinierte Claims einfügen, die deine Anwendung benötigt.
Nicht ohne es ungültig zu machen. Wenn du einen Teil des Headers oder Payloads änderst und nicht den geheimen Schlüssel besitzt, um das Token neu zu signieren, ist die resultierende Signatur falsch und der Server lehnt das Token ab. Es gibt jedoch bekannte Schwachstellen: den alg:none-Angriff (der Header deklariert keinen Algorithmus, um die Überprüfung zu umgehen) und RS256/HS256-Algorithmusverwechslung. Verwende immer eine gut gewartete JWT-Bibliothek, die diese Fälle explizit behandelt.
Session-Cookies speichern eine ID auf dem Server (zustandsbehaftet), während JWT alle Informationen im Token selbst enthält (zustandslos). JWT skaliert besser in verteilten Architekturen und Microservices, da keine gemeinsamen Sessions benötigt werden. JWT hat jedoch Nachteile: Ein Token kann vor Ablauf nicht widerrufen werden, ohne zusätzliche Infrastruktur (Blacklist), und wenn das Token gestohlen wird, bleibt es bis zum Ablauf gültig. Für die meisten traditionellen Webanwendungen bleiben httpOnly-Session-Cookies die sicherere Standardwahl.
JWT: Geschichte, technischer Aufbau und Sicherheit im Detail
JSON Web Token wurde von der IETF im Mai 2015 als RFC 7519 standardisiert, als Teil des JOSE-Frameworks (JSON Object Signing and Encryption). JOSE umfasst auch JWS (JSON Web Signature, RFC 7515), JWE (JSON Web Encryption, RFC 7516), JWK (JSON Web Key, RFC 7517) und JWA (JSON Web Algorithms, RFC 7518). Die Arbeit am Standard begann 2011 unter der Leitung von Mike Jones (Microsoft), John Bradley und Nat Sakimura. Vor JWT verließen sich Entwicklerinnen und Entwickler auf SAML (Security Assertion Markup Language), einen XML-basierten Standard, der erheblich ausführlicher und komplexer war.
Ein JWT besteht aus drei durch Punkte getrennten, Base64URL-kodierten Teilen. Base64URL unterscheidet sich von Standard-Base64 durch den Ersatz von + durch - und / durch _ sowie das Weglassen der =-Auffüllung, wodurch es in URLs und HTTP-Headern ohne zusätzliche Kodierung verwendet werden kann. Der Header gibt den Token-Typ (typ: JWT) und den Signierungsalgorithmus (alg) an. Die häufigsten Algorithmen sind HS256 (HMAC-SHA256, symmetrischer Schlüssel), RS256 (RSA-SHA256, asymmetrischer Schlüssel), ES256 (ECDSA-SHA256, P-256-Kurve) und das gefährliche none (keine Signatur, das in der Produktion niemals akzeptiert werden darf).
Die kritischsten JWT-Schwachstellen sind in OWASP API Security Top 10 gut dokumentiert. Die alg:none-Schwachstelle (CVE-2015-9235 in mehreren Bibliotheken) ermöglicht es einem Angreifer, den Header so zu ändern, dass keine Signatur erforderlich ist, sodass der Server einen beliebigen Payload akzeptiert, wenn die Bibliothek den Algorithmus nicht explizit validiert. RS256/HS256-Algorithmusverwechslung tritt auf, wenn ein für RS256 konfigurierter Server auch HS256 akzeptiert: Der Angreifer kann den öffentlichen RSA-Schlüssel (der per Definition öffentlich ist) als HMAC-Geheimschlüssel verwenden, um gefälschte Tokens zu signieren. Moderne Bibliotheken wie jose, python-jose und jsonwebtoken lösen diese Probleme, indem sie verlangen, dass der Algorithmus bei der Überprüfung explizit angegeben wird.