JWT-Tokens in Ihrem Browser dekodieren und verifizieren

Wenn Sie mit einem modernen Web-Authentifizierungssystem gearbeitet haben — OAuth 2.0, OpenID Connect oder einer eigenen API —, sind Sie mit ziemlicher Sicherheit auf JWT-Tokens gestoßen. Sie tauchen in Authorization-Headern, in Cookies, im Local Storage und in Debugging-Sitzungen um 2 Uhr morgens auf, wenn ein Login-Ablauf auf mysteriöse Weise fehlschlägt. Zu verstehen, was ein JWT tatsächlich enthält, wie man es liest und wie man häufige Probleme erkennt, beschleunigt das Authentifizierungs-Debugging dramatisch.

Mit dem BrowseryTools JWT-Decoder können Sie jedes JWT-Token einfügen und sofort dessen dekodierten Header, die Nutzlast und den Ablaufstatus sehen — alles in Ihrem Browser, wobei das Token niemals Ihr Gerät verlässt.

Was ist ein JWT?

JWT steht für JSON Web Token, definiert in RFC 7519. Ein JWT ist ein kompaktes, URL-sicheres Token, das einen Satz von Claims codiert — Aussagen über ein Subjekt, typischerweise einen Benutzer — in einem Format, das verifiziert und für vertrauenswürdig gehalten werden kann. Die zentrale Eigenschaft eines JWT ist, dass esin sich geschlossen ist: Das Token selbst trägt alle Informationen, die ein Server zur Authentifizierung einer Anfrage benötigt, ohne eine Datenbankabfrage.

Ein JWT sieht so aus:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c3JfODQyMTkiLCJuYW1lIjoiSmFuZSBEb2UiLCJlbWFpbCI6ImphbmUuZG9lQGV4YW1wbGUuY29tIiwicm9sZXMiOlsidXNlciIsImVkaXRvciJdLCJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJhdWQiOiJodHRwczovL2FwaS5leGFtcGxlLmNvbSIsImlhdCI6MTczODM2ODAwMCwiZXhwIjoxNzM4MzcxNjAwLCJqdGkiOiI3ZjNhOWI0Yy0xZDJlLTQ1NmYtYWJjZC04OTAxMjM0NTY3ODkifQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Auf den ersten Blick sieht es wie Kauderwelsch aus. Doch es hat eine sehr präzise Struktur: drei Base64URL-kodierte Abschnitte, durch Punkte getrennt. Jeder Abschnitt hat einen bestimmten Zweck.

Die dreiteilige Struktur: Header.Nutzlast.Signatur

Teil 1: Der Header

Das erste Segment, vor dem ersten Punkt, ist der Header. Es ist ein Base64URL-kodiertes JSON-Objekt, das den Typ des Tokens und den Signaturalgorithmus beschreibt. Dekodiert sieht der Header aus dem obigen Beispiel so aus:

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

Das Feld alg gibt den Signaturalgorithmus an. Gängige Werte, denen Sie begegnen werden, sind:

• HS256 — HMAC mit SHA-256. Verwendet einen gemeinsamen geheimen Schlüssel. Sowohl Aussteller als auch Prüfer müssen dasselbe Secret besitzen. Verbreitet in monolithischen Anwendungen.
• RS256 — RSA-Signatur mit SHA-256. Verwendet ein öffentliches/privates Schlüsselpaar. Der Aussteller signiert mit dem privaten Schlüssel; Prüfer kontrollieren mit dem öffentlichen Schlüssel. Verbreitet in verteilten Systemen und bei OAuth-Anbietern.
• ES256 — ECDSA mit P-256 und SHA-256. Wie RS256, aber unter Verwendung elliptischer Kurven — kürzere Schlüssel, gleiches Sicherheitsniveau. Bevorzugt in modernen Hochleistungssystemen.
• none — Keine Signatur. Akzeptieren Sie dies niemals in der Produktion. Eine notorische Sicherheitslücke entsteht, wenn Server unsignierte Tokens akzeptieren, weil der Client alg auf "none" geändert hat.

Teil 2: Die Nutzlast

Das zweite Segment ist die Nutzlast — die eigentlichen Daten, die das Token trägt. Auch sie ist ein Base64URL-kodiertes JSON-Objekt. Die dekodierte Nutzlast aus unserem Beispiel:

{
  "sub": "usr_84219",
  "name": "Jane Doe",
  "email": "jane.doe@example.com",
  "roles": ["user", "editor"],
  "iss": "https://auth.example.com",
  "aud": "https://api.example.com",
  "iat": 1738368000,
  "exp": 1738371600,
  "jti": "7f3a9b4c-1d2e-456f-abcd-890123456789"
}

Die Nutzlast enthält zwei Arten von Claims: registrierte Claims, die durch die JWT-Spezifikation definiert sind, und private/benutzerdefinierte Claims, die von Ihrer Anwendung hinzugefügt werden (wie name, email und roles oben).

Teil 3: Die Signatur

Das dritte Segment ist die Signatur. Sie wird berechnet, indem man den Base64URL-kodierten Header, einen Punkt, die Base64URL-kodierte Nutzlast nimmt und das Ergebnis mit dem im Header angegebenen Algorithmus und Schlüssel signiert. Für HS256:

HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)

Die Signatur stellt die Integrität sicher: Wenn jemand auch nur ein einziges Zeichen im Header oder in der Nutzlast nach der Ausstellung des Tokens ändert, wird die Signatur ungültig und die Verifizierung schlägt fehl. Ohne Kenntnis des Signatur-Secrets (oder des privaten Schlüssels des Ausstellers bei RS256/ES256) kann ein Angreifer kein gültiges Token fälschen.

Referenz der Standard-JWT-Claims

Warum der exp-Claim entscheidend ist

Der exp-Claim ist ein Unix-Zeitstempel — die Anzahl der Sekunden seit dem 1. Januar 1970 (UTC). In unserem Beispiel "exp": 1738371600. Um dies in ein menschenlesbares Datum umzuwandeln, können Sie JavaScript verwenden:

new Date(1738371600 * 1000).toUTCString()
// → "Sat, 01 Feb 2026 01:00:00 GMT"

Der JWT-Ablauf ist das Erste, das man prüfen sollte, wenn ein Token abgelehnt wird. Ein Token, das gestern gültig war, schlägt heute fehl, wenn sein exp in der Vergangenheit liegt — das ist so beabsichtigt. Kurzlebige Tokens (15 Minuten bis 1 Stunde) begrenzen das Schadensfenster, falls ein Token gestohlen wird. Längerlebige Tokens (Tage oder Wochen) sind bequemer, aber gefährlicher, wenn sie kompromittiert werden.

Der BrowseryTools JWT-Decoder liest automatisch die exp- und iat-Claims aus und zeigt sie neben den rohen Unix-Zeitstempeln als menschenlesbare Daten an, sodass Sie die Kopfrechnung niemals manuell durchführen müssen.

Häufige JWT-Debugging-Szenarien

Token abgelaufen (401 Unauthorized)

Der häufigste JWT-Fehler. Der Server hat das Token abgelehnt, weil die aktuelle Zeit nach demexp-Wert liegt. Lösung: Implementieren Sie einen Token-Refresh-Ablauf mit einem längerlebigen Refresh-Token oder authentifizieren Sie sich einfach neu. Fügen Sie das Token in den Decoder ein, um genau zu bestätigen, wann es abgelaufen ist.

Falscher Empfänger

Wenn Ihre API den aud-Claim validiert und das Token für einen anderen Empfänger ausgestellt wurde (z. B. ein für https://api-staging.example.com ausgestelltes Token wird an https://api.example.com gesendet), wird der Server es ablehnen. Dekodieren Sie das Token und prüfen Sie das aud-Feld, um zu bestätigen, dass es dem entspricht, was der empfangende Dienst erwartet.

Algorithmus-Diskrepanz

Wenn Ihr Server RS256 erwartet, aber ein mit HS256 signiertes Token empfängt (oder umgekehrt), schlägt die Validierung fehl. Das kann während einer Schlüsselrotation oder beim Wechsel von Auth-Anbietern geschehen. Prüfen Sie das alg-Feld im dekodierten Header gegen das, was Ihr Server zu akzeptieren konfiguriert ist.

Signatur ungültig

Wenn die Nutzlast manipuliert wurde — selbst ein einzelnes geändertes Zeichen —, stimmt die Signatur nicht überein. Das passiert auch, wenn Sie das falsche Secret oder den falschen öffentlichen Schlüssel zur Verifizierung verwenden. Das Dekodieren von Header und Nutzlast (was kein Secret erfordert) erlaubt es Ihnen zumindest zu prüfen, was das Token behauptet, selbst wenn Sie seine Echtheit clientseitig nicht verifizieren können.

JWT vs. Session-Tokens: Wann man welches verwendet

JWTs und herkömmliche Session-Tokens lösen dasselbe Problem — die Identifizierung eines authentifizierten Benutzers über mehrere Anfragen hinweg —, tun das aber unterschiedlich, und keines ist universell besser.

Herkömmliche Session-Tokens sind undurchsichtige zufällige Zeichenketten (z. B. eine UUID), die serverseitig in einem Session-Speicher (Redis, Datenbank) abgelegt werden. Bei jeder Anfrage schlägt der Server das Token im Speicher nach und ruft die Benutzerdaten ab. Der Server hat volle Kontrolle: Das Ungültigmachen einer Sitzung entzieht den Zugriff sofort.

JWTs sind zustandslos. Der Server stellt ein signiertes Token aus und führt keine Aufzeichnung darüber. Bei jeder Anfrage verifiziert der Server die Signatur und vertraut den Claims ohne jede Datenbankabfrage. Das skaliert horizontal ohne gemeinsamen Zustand — jeder Server mit dem Verifizierungsschlüssel kann die Anfrage authentifizieren. Der Kompromiss: Sie können ein JWT vor seinem Ablauf nicht sofort widerrufen (es sei denn, Sie implementieren eine Token-Sperrliste, die wieder Zustand einführt).

• Verwenden Sie JWTs für zustandslose Microservices, verteilte Systeme, mobile APIs und domänenübergreifende Authentifizierung (OAuth/OIDC-Abläufe). Halten Sie die Ablaufzeiten kurz.
• Verwenden Sie Session-Tokens, wenn Sie eine sofortige Widerrufsmöglichkeit benötigen (Abmeldung, Kontosperrung, Sicherheitsvorfälle), oder wenn alle Ihre Dienste einen schnellen Session-Speicher teilen.

So nutzen Sie den BrowseryTools JWT-Decoder

Öffnen Sie den JWT-Decoder und fügen Sie Ihr Token in das Eingabefeld ein. Das Tool teilt das Token sofort an den beiden Punkten auf und zeigt Folgendes an:

• Header-Bereich: Das dekodierte JSON, das alg, typ und alle anderen Header-Felder zeigt. Nützlich, um den Signaturalgorithmus auf einen Blick zu erkennen.
• Nutzlast-Bereich: Das vollständige dekodierte JSON mit allen Claims. Zeitstempel werden sowohl im rohen Unix-Format als auch als menschenlesbare UTC-Daten angezeigt, sodass Sie den Ablauf sofort ohne gedankliche Umrechnung sehen können.
• Ablaufstatus: Eine klare Anzeige, die zeigt, ob das Token derzeit gültig, bereits abgelaufen oder noch nicht aktiv ist (basierend auf nbf). Falls abgelaufen, sehen Sie genau, vor wie langer Zeit es abgelaufen ist.
• Signatur-Segment: Die rohe Base64URL-kodierte Signatur, zur Referenz angezeigt. Das Tool verifiziert die Signatur nicht (das erfordert das Secret oder den öffentlichen Schlüssel), aber es dekodiert und zeigt alle Informationen an, die Sie zum Debuggen benötigen.

Es gibt keine Formularübermittlung, keine Serveranfrage, keinen Zwischenablagezugriff über das hinaus, was Sie ausdrücklich einfügen. Das Parsen des Tokens erfolgt vollständig in JavaScript, das in Ihrem Browser-Tab läuft.

Dekodieren Sie jetzt Ihr JWT-Token

Ob Sie ein abgelaufenes Token debuggen, Claims von einem OAuth-Anbieter untersuchen, prüfen, welche Rollen einem Benutzer gewährt wurden, oder einfach verstehen möchten, was Ihr Authentifizierungssystem tatsächlich ausstellt — der BrowseryTools JWT-Decoder liefert Ihnen die Antworten sofort. Keine Registrierung, keine zu installierenden Erweiterungen, keine Daten, die irgendwohin gesendet werden.