Einen JSON Web Token (JWT) decodieren

Was ist ein JWT (JSON Web Token)?

Ein JSON Web Token, abgekürzt JWT (ausgesprochen "jot"), ist ein kompaktes Format, das in der RFC 7519 definiert ist und es ermöglicht, eine Reihe von Behauptungen (Claims) zwischen zwei Parteien zu transportieren. Das JWT, oder JWT-Token, ist heute das dominante Format, um eine authentifizierte Identität in einer HTTP-API zu transportieren. Ein JWT erscheint als ASCII-Zeichenkette, die aus drei durch Punkte getrennten Segmenten besteht:

header.payload.signature

Jedes Segment ist in Base64URL kodiert, einer Base64-Variante ohne Padding =, die + durch - und / durch _ ersetzt, damit es ohne zusätzliches Escaping in einer URL oder einem HTTP-Header transportiert werden kann.

Anatomie eines JWT

Ein JSON Web Token besteht aus drei klar unterscheidbaren Teilen, von denen jeder eine präzise Rolle im Authentifizierungsmechanismus spielt:

1. Header

Der Header ist ein JSON-Objekt, das beschreibt, wie das Token signiert ist. Er enthält mindestens:

• alg (algorithm): der verwendete Signaturalgorithmus. Typische Werte: HS256, RS256, ES256, EdDSA.
• typ (type): der Tokentyp, fast immer "JWT".
• kid (key ID): optional, identifiziert welcher Schlüssel zur Überprüfung der Signatur verwendet werden soll. Praktisch bei einem Bestand rotierender Schlüssel (JWKS).

2. Payload

Das Payload enthält die Claims, also die Behauptungen, die der Aussteller über den Benutzer oder die Sitzung macht. Die RFC 7519 definiert sieben Standard-Claims (registered claims):

• iss (issuer): wer das Token ausgestellt hat, zum Beispiel "https://accounts.google.com".
• sub (subject): wem das Token gehört, in der Praxis die Benutzer-ID.
• aud (audience): an wen das Token gerichtet ist. Verhindert, dass ein für die API A ausgestelltes Token von der API B akzeptiert wird.
• exp (expiration time): Unix-Timestamp, nach dem das Token nicht mehr gültig ist.
• nbf (not before): Timestamp, vor dem das Token noch nicht aktiv ist.
• iat (issued at): Ausstellungs-Timestamp des Tokens.
• jti (JWT ID): eindeutiger Token-Bezeichner, verwendet für Widerruf und Replay-Prävention.

Zu diesen Standard-Claims kommen in der Regel Custom-Claims, die für die Anwendung spezifisch sind (roles, scope, tenant_id, email, permissions...).

3. Signatur

Die Signatur ist eine kryptografische Prüfsumme, berechnet über base64url(header) + "." + base64url(payload) mithilfe eines Schlüssels. Sie beweist, dass niemand den Header oder das Payload seit der Ausstellung verändert hat. Die gängigsten Algorithmen:

• HS256 / HS384 / HS512: symmetrische HMAC-SHA-Signatur. Ein zwischen Aussteller und Überprüfer geteilter geheimer Schlüssel. Einfach, aber ungeeignet, sobald es mehr als einen Konsumenten gibt.
• RS256 / RS384 / RS512: asymmetrische RSA-Signatur. Der Aussteller signiert mit seinem privaten Schlüssel, jeder Konsument überprüft mit dem entsprechenden öffentlichen Schlüssel. De-facto-Standard für OAuth2 und OpenID Connect.
• ES256 / ES384 / ES512: asymmetrische ECDSA-Signatur. Dieselben Eigenschaften wie RS256, aber mit deutlich kürzeren Schlüsseln und Signaturen.
• EdDSA (Ed25519): moderne asymmetrische Signatur, schnell und kompakt.

Nochmals: Die Signatur schützt die Integrität, nicht die Vertraulichkeit. Das Payload bleibt für jeden lesbar, der das Token besitzt.

Warum ein JWT dekodieren?

Die Operation jwt token decode deckt mehrere konkrete Bedürfnisse für einen Entwickler oder Sicherheitsingenieur ab:

• Authentifizierungs-Debugging: Ihre API gibt einen 401 oder 403 zurück, und Sie möchten sehen, was sich tatsächlich im Payload befindet (sub, scope, roles, exp), statt zu raten.
• Claims überprüfen: bestätigen, dass ein Token tatsächlich die erwartete Behauptung enthält (zum Beispiel tenant_id oder permissions), bevor man anderswo in der Autorisierungskette sucht.
• Ablauf lesen: den exp-Timestamp in ein menschliches Datum umwandeln, um zu bestätigen, dass ein Token tatsächlich abgelaufen ist, oder im Gegenteil, dass es noch gültig sein sollte.
• Sicherheitsaudit: sicherstellen, dass ein Drittanbieterdienst keine sensiblen Informationen im Payload preisgibt (E-Mails, interne Bezeichner, personenbezogene Daten).
• Schulung und Verständnis: konkret sehen, wie ein jsonwebtoken aussieht, das von einem OAuth-Anbieter (Google, Auth0, Keycloak, AWS Cognito) ausgegeben wird, um die Mechanik zu verstehen, ohne in die Doku einzutauchen.
• Erkundung öffentlicher Tokens: ein in Logs, in einem Cookie oder in einem abfangbaren OAuth-Austausch gefundenes JWT inspizieren.

Decoder vs. Verifier: die kritische Unterscheidung

Die beiden Operationen wirken ähnlich, haben aber hinsichtlich der Sicherheitsgarantien nichts miteinander zu tun:

• Ein JWT dekodieren besteht darin, die Zeichenkette an den . zu teilen und auf die beiden ersten Segmente ein Base64URL-Inverses anzuwenden. Das ist ein einfaches Lesen, in jedem Drei-Zeilen-Skript machbar. Es findet keine Signaturüberprüfung statt.
• Ein JWT überprüfen besteht darin, die Signatur aus Header, Payload und einem Schlüssel neu zu berechnen und das Ergebnis mit der im Token vorhandenen Signatur zu vergleichen. Das ist es, was garantiert, dass das Token nicht gefälscht wurde.

Praktische Schlussfolgerung: Dekodieren bedeutet nicht Vertrauen. Solange die Signatur nicht mit dem richtigen Schlüssel überprüft wurde, kann der Inhalt des Payload völlig erfunden sein. Für die Vertrauensphase verwenden Sie unseren JWT Verifier.

So verwenden Sie es

1. Holen Sie sich das zu inspizierende JWT, zum Beispiel aus einem Authorization: Bearer <jwt>-Header, aus einem Session-Cookie, aus dem localStorage des Browsers oder aus einem Anwendungs-Log.
2. Fügen Sie die vollständige Zeichenkette in das Eingabefeld ein. Die drei Segmente müssen durch Punkte getrennt bleiben.
3. Das Tool zeigt sofort den dekodierten Header als formatiertes JSON an, mit dem Algorithmus und dem Typ.
4. Das Payload wird anschließend dekodiert und angezeigt. Sie sehen darin alle Standard- und Custom-Claims.
5. Das Tool zeigt auch die Signaturinformation an (deklarierter Algorithmus, Länge), ohne sie zu überprüfen.
6. Um zu bestätigen, dass das Token nicht gefälscht wurde, wechseln Sie zu unserem JWT Verifier mit dem öffentlichen Schlüssel oder dem erwarteten Secret.

Die gesamte Dekodierung erfolgt in Ihrem Browser in JavaScript: Ihr Token wird nie an unsere Server gesendet.

JWT und Sicherheit: die zu vermeidenden Fallen

Einige goldene Regeln zur korrekten Verwendung von JWTs in der Produktion:

• Überprüfen Sie die Signatur immer serverseitig, bevor Sie irgendein Recht gewähren. Unser JWT Verifier illustriert genau diese Operation.
• Bevorzugen Sie RS256 oder ES256 gegenüber HS256 für öffentliche APIs. Die asymmetrische Signatur vermeidet das Teilen eines Secrets zwischen Aussteller und jedem Konsumenten.
• Halten Sie sich immer an den Claim exp. Ein JWT ohne Ablauf oder mit zu fernem Ablauf ist eine Zeitbombe im Falle einer Kompromittierung.
• Validieren Sie iss und aud serverseitig, um zu vermeiden, dass ein legitimes Token, das für einen anderen Dienst ausgestellt wurde, versehentlich akzeptiert wird.
• Lehnen Sie alg: "none" ab bei der Überprüfung. Das ist eine klassische Schwachstelle, die es einem Angreifer ermöglicht, jedes beliebige Payload zu schmieden.
• Halten Sie die Lebensdauer kurz (zum Beispiel 15 Minuten) und koppeln Sie mit einem längeren, aber serverseitig widerrufbaren Refresh-Token.

Beispiel eines dekodierten JWT-Tokens

Hier ist ein typisches JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiSm9obiIsImlhdCI6MTUxNjIzOTAyMn0.jrU9j8LZcRK2_BZjqXjU7lEpJbkqmXfTQIu9vT45j-I

Einmal dekodiert, ist hier sein Inhalt:

// Header
{
  "alg": "HS256",
  "typ": "JWT"
}

// Payload
{
  "sub": "123",
  "name": "John",
  "iat": 1516239022
}

// Signature (binaire, encodé en Base64URL)
HMACSHA256(
  base64url(header) + "." + base64url(payload),
  secret
)

Wo findet man ein JWT zum Kopieren?

In der Praxis stammt ein zu dekodierendes (im Sinne von dekodierendes) JWT meist aus einem dieser Orte:

• HTTP-Cookie: Öffnen Sie die Entwicklerwerkzeuge (F12), Tab Application oder Storage, dann Cookies. Suchen Sie nach einem Cookie namens access_token, jwt, session oder ähnlich.
• localStorage / sessionStorage: Gleiches Panel, Abschnitt Local Storage. Viele SPAs speichern dort ihr Token unter einem token- oder auth-Schlüssel.
• Authorization-Header: Tab Network, eine API-Anfrage auswählen, den Header Authorization: Bearer <jwt> lesen. Nur den Teil nach Bearer kopieren.
• Server-Logs: Ein JWT erscheint manchmal in den Logs eines Gateways oder eines Reverse-Proxys (in der Produktion zu vermeiden, aber beim Debuggen nützlich).

Häufig gestellte Fragen

Beispielanfrage

curl -X POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute \
  -H "Content-Type: application/json" \
  -d '{"token":"..."}'

Eingabeschema

Endpunkte

• GET https://cdrn.fr/api/v1/tools - listet alle verfügbaren Tools auf
• GET https://cdrn.fr/api/v1/tools/jwt-decoder - liefert das Schema dieses Tools
• POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute - führt dieses Tool mit einem JSON-Payload aus