JWT Token dekodieren: vollständiger Entwickler-Leitfaden

Ihre API hat gerade 401 Unauthorized zurückgegeben. Der Header Authorization: Bearer eyJhbGciOi... sieht in Ordnung aus. War der Token abgelaufen, stimmte die Audience nicht, oder hat der Issuer einen Schlüssel rotiert? Diese Frage beantworten Sie erst, wenn Sie den Inhalt des Tokens lesen, und zum Dekodieren eines JWT-Tokens brauchen Sie kein Geheimnis, keine Bibliothek und nicht einmal eine Netzwerkverbindung. Ein JWT besteht aus drei Base64URL-kodierten Abschnitten, verbunden durch Punkte. Das Dekodieren ist rein mechanisch: trennen, Base64URL dekodieren, JSON.parse anwenden. Keine Magie, keine Kryptografie.

Dieser Leitfaden führt durch den Aufbau, zeigt Ihnen die Dekodierung eines JWT in Node.js, Python, Go und im Browser, klärt den Unterschied zwischen Dekodieren und Verifizieren, an dem die meisten Teams stolpern, und listet die echten Fehlerquellen auf, die Sie treffen werden. Wenn Sie sofort einen Token inspizieren müssen, springen Sie zu unserem kostenlosen JWT-Dekodierer; er läuft vollständig in Ihrem Browser, sodass Produktions-Token Ihr Gerät nie verlassen.

Was ist ein JWT? (Kurzer Aufbau)

Ein JSON Web Token (JWT) ist ein kompaktes, URL-sicheres Credential, definiert in RFC 7519. Er transportiert Claims, also Daten über den Benutzer und den Token selbst, zwischen zwei Parteien. Ein JWT besteht aus drei Base64URL-kodierten Teilen, verbunden durch Punkte: einem Header, einer Payload und einer Signatur.

Hier ist ein echter Token zerlegt, damit Sie die Struktur erkennen:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9       ← header
.
eyJzdWIiOiJ1c2VyXzEyMyIsImV4cCI6MTk5OTk5OTk5OX0   ← payload
.
4NhxPjwoZxPNuxG-2C5ugGxaUsUJ0QyskAz7Ymz5Sg0       ← signature

Der Header beschreibt, wie der Token signiert ist, meistens { "alg": "HS256", "typ": "JWT" }. Die Payload trägt die Claims: registrierte wie sub, exp, iat sowie benutzerdefinierte wie role oder tenant. Die Signatur ist ein kryptografischer Beweis über Header und Payload, mit dem der Empfänger Manipulationen erkennt. Base64URL ist eine URL-sichere Variante von Base64; siehe unseren einsteigerfreundlichen Base64-Leitfaden für die zehnminütige Einführung.

JWTs begegnen Ihnen überall dort, wo moderne Authentifizierung lebt: OAuth-2.0-Access-Tokens, OpenID-Connect-ID-Tokens, API-Credentials von Auth0, Okta, Clerk, Supabase, Firebase und Token, die zwischen Microservices in einem Mesh ausgetauscht werden. Sie sind das Standard-Credential-Format des letzten Jahrzehnts.

Bevor wir weitergehen, eine Zeile zum Einprägen: JWTs sind kodiert, nicht verschlüsselt. Jeder, der den Token besitzt, kann jeden Claim lesen. Die Signatur beweist die Herkunft; sie verbirgt den Inhalt nicht. Dieser eine Fakt bestimmt alles Weitere in diesem Leitfaden: was sicher in die Payload gehört, warum das Dekodieren kein Geheimnis braucht, warum die Signaturprüfung serverseitig nicht verhandelbar ist.

Wie JWT-Dekodierung funktioniert (Base64URL, keine Entschlüsselung)

Das Dekodieren eines JWT ist keine kryptografische Operation. Es sind vier mechanische Schritte:

1. Den Token an . in genau drei Segmente teilen.
2. Das erste Segment Base64URL-dekodieren und als JSON parsen. Das ist der Header.
3. Das zweite Segment Base64URL-dekodieren und als JSON parsen. Das ist die Payload.
4. Das dritte Segment (die Signatur) als Rohbytes belassen. Die Verifikation benötigt den Schlüssel.

Das ist der gesamte Algorithmus. Eine Bibliothek ist nicht zwingend nötig. Jede Sprache mit Base64 und einem JSON-Parser dekodiert einen JWT in fünf Zeilen. Unser Base64-Kodierer/Dekodierer erledigt Schritt 2 und 3 von Hand, falls Sie die Mechanik sehen möchten.

Was ist Base64URL?

Base64URL ist einfaches Base64 mit drei Anpassungen, damit die Ausgabe in URLs und HTTP-Headern sicher ist: - ersetzt +, _ ersetzt /, und das abschließende =-Padding entfällt. Wenn Sie rohes Base64URL ohne Umkehrung dieser Ersetzungen in einen Standard-Base64-Dekodierer füttern, bekommen Sie entweder Müll oder einen Fehler. Der ausführliche Base64-Leitfaden behandelt die Padding-Edge-Cases im Detail.

	Standard-Base64	Base64URL
Alphabet	A-Z a-z 0-9 + /	A-Z a-z 0-9 - _
Padding	= am Ende erforderlich	Entfällt
URL-sicher?	Nein	Ja
Beispiel	PDw/Pz8+	PDw_Pz8-

Noch ein Hinweis, der die Tinte wert ist: Sie können die Signatur clientseitig nicht entschlüsseln. Dekodierung ist eine Einbahnstraße von kodierten Bytes zu JSON. Die Signaturprüfung ist eine separate Operation, die entweder das HMAC-Geheimnis (für HS-Algorithmen) oder den öffentlichen Schlüssel des Issuers (für RS, PS, ES, EdDSA) benötigt.

Warum Sie zum Dekodieren kein Geheimnis brauchen

Weil die Payload Base64URL plus JSON ist, kein Chiffretext. Ein Geheimnis kommt erst ins Spiel, wenn Sie beweisen wollen, dass der Token nicht manipuliert wurde, also bei der Signaturprüfung. Jeder auf dem Netzwerkpfad, jeder, der den Token in einer Logzeile hält, jeder mit einem Browser kann jeden Claim lesen, den Sie hineinlegen. Deshalb dürfen Sie niemals Passwörter, API-Schlüssel oder PII, die über das hinausgehen, was der Empfänger bereits kennt, in eine JWT-Payload packen. Für das umfassendere Bedrohungsmodell lesen Sie unseren Leitfaden zu Sicherheits-Best-Practices.

JWT online dekodieren in 3 Klicks: kostenloser JWT-Dekodierer

Manchmal brauchen Sie einfach sofort eine Antwort: Ist dieser Token abgelaufen, stimmt der aud-Claim mit meiner Annahme überein, sagt der Header alg:none? Der schnellste Weg ist unser Online-JWT-Dekodierer. Er ist für den Notfall um zwei Uhr nachts gebaut.

1. Einfügen: Kopieren Sie den vollständigen Token in das Eingabefeld. Alle drei punktgetrennten Segmente einschließen.
2. Lesen: Dekodierten Header, Payload und die Status-Chips oben prüfen: Algorithmus, Ausstellungszeit, Ablauf sowie ein rotes Badge Abgelaufen, falls exp bereits in der Vergangenheit liegt.
3. Kopieren: Beliebiges Panel in Ihren Bugreport, Slack-Thread oder Test-Fixture übernehmen.

Warum er für echte Produktions-Token sicher ist:

• 100 % browserbasiert. Die Dekodierung läuft über natives atob und JSON.parse. Keine Netzwerkanfrage, niemals.
• Kein Logging, kein Tracking, keine Cookies, keine Anmeldung.
• Funktioniert offline, sobald die Seite geladen ist.

Das JWT-Dekodierer-Tool ist algorithmusunabhängig. Da die Dekodierung nur Base64URL und JSON benötigt, liest es jede JWS-Variante: HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512, EdDSA und alg:none. Nur die Signaturprüfung hängt vom Algorithmus ab, und die Verifikation sollte kein öffentliches Web-Tool übernehmen; mehr dazu gleich.

Müssen Sie ein Segment manuell Base64-dekodieren, um das Tool gegenzuprüfen? Nutzen Sie unseren Base64-Kodierer/Dekodierer und geben Sie jedes Segment als Base64URL ein.

JWT im Code dekodieren (Node.js, Python, Go, Browser)

Für alles, was nicht interaktives Debugging ist (Middleware, Tests, Migrationsskripte, CLI-Tools), greifen Sie zu einer Bibliothek. Hier ist der minimale Code, um einen JWT in den vier Umgebungen zu dekodieren, die Ihnen am wahrscheinlichsten begegnen, jeweils mit dem Nur-Lese-Pfad und dem Verifikationspfad nebeneinander. Jeder Snippet ist kopierbereit und erzeugt die in den Kommentaren gezeigten Ausgaben.

JWT in Node.js dekodieren (jsonwebtoken)

// npm install jsonwebtoken
const jwt = require('jsonwebtoken');

const token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9' +
              '.eyJzdWIiOiJ1c2VyXzEyMyIsImV4cCI6MTk5OTk5OTk5OX0' +
              '.4NhxPjwoZxPNuxG-2C5ugGxaUsUJ0QyskAz7Ymz5Sg0';

// Nur dekodieren — prüft die Signatur NICHT
const decoded = jwt.decode(token, { complete: true });
console.log(decoded.header);   // { alg: 'HS256', typ: 'JWT' }
console.log(decoded.payload);  // { sub: 'user_123', exp: 1999999999 }

// Verifizieren — der Produktionspfad
const secret = process.env.JWT_SECRET;
const verified = jwt.verify(token, secret, { algorithms: ['HS256'] });

Übergeben Sie immer eine explizite algorithms-Allowlist an verify. Wurde sie weggelassen, konnten Angreifer historisch einen RS256-Token zu HS256 herabstufen, indem sie den öffentlichen Schlüssel als HMAC-Geheimnis signierten: der klassische Algorithmus-Verwirrungs-Angriff. Die Allowlist ist Ihre Verteidigung.

JWT in Python dekodieren (PyJWT)

# pip install PyJWT
import jwt

token = (
    "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9"
    ".eyJzdWIiOiJ1c2VyXzEyMyIsImV4cCI6MTk5OTk5OTk5OX0"
    ".4NhxPjwoZxPNuxG-2C5ugGxaUsUJ0QyskAz7Ymz5Sg0"
)

# Nur dekodieren — für Auth unsicher, für Inspektion ok
decoded = jwt.decode(token, options={"verify_signature": False})
print(decoded)  # {'sub': 'user_123', 'exp': 1999999999}

# Header ohne Zugriff auf die Payload
header = jwt.get_unverified_header(token)
print(header)   # {'alg': 'HS256', 'typ': 'JWT'}

# Verifizieren — Produktionspfad
payload = jwt.decode(
    token,
    key="your-hs256-secret",
    algorithms=["HS256"],
    audience="api.example.com",
)

PyJWT verweigert die Verifikation ohne algorithms-Liste, ein sinnvoller Standard, der denselben Verwirrungs-Angriff verhindert, vor dem das Node-Beispiel warnt.

JWT in Go dekodieren (golang-jwt/jwt/v5)

// go get github.com/golang-jwt/jwt/v5
package main

import (
    "fmt"
    "github.com/golang-jwt/jwt/v5"
)

func main() {
    tokenString := "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" +
        ".eyJzdWIiOiJ1c2VyXzEyMyIsImV4cCI6MTk5OTk5OTk5OX0" +
        ".4NhxPjwoZxPNuxG-2C5ugGxaUsUJ0QyskAz7Ymz5Sg0"

    // Nur dekodieren
    parser := jwt.NewParser()
    claims := jwt.MapClaims{}
    _, _, err := parser.ParseUnverified(tokenString, claims)
    if err != nil {
        panic(err)
    }
    fmt.Println(claims["sub"], claims["exp"]) // user_123 1.999999999e+09

    // Verifizieren
    secret := []byte("your-hs256-secret")
    token, err := jwt.Parse(tokenString, func(t *jwt.Token) (interface{}, error) {
        if _, ok := t.Method.(*jwt.SigningMethodHMAC); !ok {
            return nil, fmt.Errorf("unexpected alg: %v", t.Header["alg"])
        }
        return secret, nil
    })
    fmt.Println(token.Valid, err)
}

In der keyFunc-Closure erzwingen Sie die Algorithmen-Familie: alles ablehnen, was nicht die erwartete Methode ist, bevor Sie den Schlüssel zurückgeben.

JWT im Browser dekodieren (ohne Abhängigkeiten)

Manchmal wollen Sie gar keine Abhängigkeit: ein schnelles Debug-Panel, eine Browser-Erweiterung, ein kleines UI-Badge, das die aktuelle Rolle des Benutzers zeigt. Native Browser-APIs genügen:

function decodeJwt(token) {
  const [h, p] = token.split('.');
  const pad = (s) => s + '==='.slice((s.length + 3) % 4);
  const decodeSegment = (s) => {
    const b64 = pad(s).replace(/-/g, '+').replace(/_/g, '/');
    const bytes = Uint8Array.from(atob(b64), (c) => c.charCodeAt(0));
    return JSON.parse(new TextDecoder().decode(bytes));
  };
  return { header: decodeSegment(h), payload: decodeSegment(p) };
}

const { header, payload } = decodeJwt(token);
console.log(header);   // { alg: 'HS256', typ: 'JWT' }
console.log(payload);  // { sub: 'user_123', exp: 1999999999 }

Der TextDecoder-Schritt ist entscheidend für jeden Token mit Nicht-ASCII-Payload (Emoji in einem Anzeigenamen, Kyrillisch in einem preferred_username); atob allein liefert eine Binärzeichenkette, die JSON.parse bei mehrbyte-UTF-8 sprengt. Genau das läuft bei unserem Online-JWT-Dekodierer lokal in Ihrem Browser, abzüglich der UI.

Vergleichstabelle

Sprache	Nur dekodieren	Verifizieren	Bibliothek
Node.js	jwt.decode(token)	jwt.verify(token, key, { algorithms: [...] })	jsonwebtoken
Python	jwt.decode(token, options={"verify_signature": False})	jwt.decode(token, key, algorithms=[...])	PyJWT
Go	parser.ParseUnverified(token, claims)	jwt.Parse(token, keyFunc)	golang-jwt/jwt/v5
Browser	atob + TextDecoder + JSON.parse	Fragen Sie Ihr Backend	—

Dekodieren vs. Verifizieren: der entscheidende Unterschied

Ein JWT zu dekodieren liest seine Claims; einen JWT zu verifizieren beweist, dass diese Claims nicht manipuliert wurden. Dekodieren vertraut niemals; Verifikation ist das Vertrauen. Diese einzelne Unterscheidung trennt eine funktionierende Auth-Implementierung von einer CVE.

	Dekodieren	Verifizieren
Braucht Geheimnis/Schlüssel?	Nein	Ja
Läuft clientseitig?	Sicher	Niemals
Beweist Authentizität?	Nein	Ja
Prüft Ablauf?	Optional	Ja
Anwendungsfall	Debugging, Inspektion	Authentifizierung, Autorisierung

Treffen Sie niemals eine Autorisierungsentscheidung anhand eines dekodierten (unverifizierten) JWT. Weder in Middleware, noch in einem React-Hook, noch in einer serverlosen Funktion, von der Sie glauben, sie stehe hinter dem Gateway. Dekodierte Claims sagen, was der Token behauptet; verifizierte Claims sagen, was der Issuer signiert hat. Ein Angreifer, der Ihrem Server einen handgefertigten Token ohne gültige Signatur übergibt, kann alles in die Payload schreiben, was er will; nur die Signaturprüfung weist ihn ab.

Noch ein tragender Punkt zur HMAC-Familie: Wenn Sie HS256 verwenden, entscheidet die Entropie Ihres Geheimnisses über alles. Ein kurzes, erratbares Geheimnis wird offline gegen jeden abgefangenen Token brute-forced, und dann prägen Angreifer eigene Token und spazieren durch die Vordertür. Verwenden Sie mindestens 256 Bit echte Zufälligkeit. Siehe unseren Leitfaden zur HMAC-Schlüsselstärke für die Arithmetik, warum das zählt.

Referenz gängiger JWT-Claims

Jeder JWT, dem Sie begegnen, nutzt eine Teilmenge der registrierten Claims aus RFC 7519. Merken Sie sich die kurze Liste:

Claim	Name	Beispiel	Hinweise
iss	Issuer	https://auth.example.com	Wer den Token ausgestellt hat
sub	Subject	user_123	Meist die Benutzer-ID
aud	Audience	api.example.com	Für wen der Token gedacht ist; muss serverseitig übereinstimmen
exp	Expiration	1715003600	Unix-Sekunden; Vergangenheit = abgelaufen
iat	Issued At	1715000000	Unix-Sekunden der Ausstellung
nbf	Not Before	1715000060	Früheste Zeit, zu der der Token nutzbar ist
jti	JWT ID	d1f8…	Pro Token eindeutig; verhindert Replay
kid	Key ID (Header)	key-2025-01	Welcher Schlüssel in Ihrem JWKS signiert hat

Anwendungsspezifische Claims stehen daneben: role, scope, email, tenant_id, was auch immer Ihr Identity Provider ausgibt. Halten Sie sie kurz; jedes Byte reist bei jeder Anfrage mit.

Um aus iat und exp lesbare Datumsangaben zu machen, probieren Sie unseren Unix-Zeitstempel-Konverter. Zahl einfügen, Datum in Ihrer lokalen Zeitzone erhalten, Zeitversatz-Bug in einer Sekunde entdecken.

Fehlerbehebung: warum lässt sich mein JWT nicht dekodieren?

Fünf echte Fehlerquellen, grob nach Häufigkeit sortiert. Jede nach dem Schema Symptom → Ursache → Lösung.

1. “Ungültiges JWT-Format, drei Segmente erwartet.” Sie haben nur die Payload kopiert, oder die Shell hat den Token über Zeilen umgebrochen und Sie haben nur die erste Zeile erwischt. Lösung: den vollständigen xxx.yyy.zzz-Wert aus dem ursprünglichen Response-Body neu kopieren, nicht aus einem gerenderten Terminal. Lange einzeilige Werte überleben im Netzwerk-Tab der Browser-DevTools besser als in einem gescrollten Terminal.
2. Fünf Segmente statt drei. Sie haben einen JWE (verschlüsselten JWT), keinen JWS. Das Format ist header.encryptedKey.iv.ciphertext.tag. Ein Dekodierer liest den Header, aber die Payload ist Chiffretext. Lösung: Die Payload zu dekodieren erfordert den Entschlüsselungsschlüssel, in der Regel serverseitig von Ihrem Auth-SDK erledigt, nicht von einem Debug-Tool.
3. Base64URL-Fehler bei einem ansonsten gültig aussehenden Token. Der Token wurde irgendwo auf dem Kopierweg URL-kodiert (ein Cookie, eine Redirect-URL, ein Proxy-Log). Sie sehen wörtlich %2E oder %2B in der Zeichenkette. Lösung: zuerst URL-dekodieren, dann das Ergebnis in den JWT-Dekodierer geben.
4. JSON-Parse-Fehler auf der Payload. Ein Terminal oder Chat-Client hat Soft-Wrap-Zeilenumbrüche eingefügt, oder ein Skript hat typografische Anführungszeichen um eine Kennung gesetzt. Lösung: die rohen Response-Bytes ansehen (curl mit -o file.txt oder die Raw-Ansicht der DevTools), Whitespace entfernen, erneut einfügen.
5. Dekodiert sauber, aber das Backend lehnt weiterhin ab. Kein Dekodierungsproblem, sondern ein Verifikationsproblem. Der Token ist strukturell gültig; etwas, das der Server prüft (Signatur, aud, exp, Zeitversatz, kid-Lookup), schlägt fehl. Springen Sie zum nächsten Abschnitt.

Zwei ehrenvolle Erwähnungen, die keine Parse-Fehler sind, aber es wert sind, abgefangen zu werden, solange der Dekodierer offen ist: ein alg-Wert von none im Header (in Produktion als feindlich behandeln) und ein exp-Wert in der Vergangenheit (der Dekodierer zeigt die Claims weiterhin, damit Sie debuggen können; das ist korrektes Verhalten, und unser Tool kennzeichnet es mit einem roten Badge Abgelaufen).

Wenn Dekodieren nicht reicht: Signaturprüfung

Das Dekodieren endet bei “hier steht, was der Token behauptet”. Die Verifikation verwandelt einen Claim in eine Vertrauensentscheidung. Die Signatur ist ein Beweis, berechnet mit dem privaten Schlüssel oder dem gemeinsamen Geheimnis des Issuers, der Header und Payload miteinander verknüpft: ändern Sie ein einziges Byte, und die Signaturprüfung schlägt fehl. Ohne diese Prüfung kann jeder, der an Ihren Endpunkt POSTen kann, einen “admin”-Token handwerken, indem er die Payload bearbeitet und die Signatur ganz überspringt.

Akzeptieren Sie niemals alg:none.

Produktionsverifikation sieht in jeder Sprache und jedem Framework ungefähr wie diese Checkliste aus. Fehlende Punkte als Bug behandeln:

• Eine explizite algorithms: ['RS256']-Allowlist (oder was immer Sie nutzen) übergeben. Das wehrt Algorithmus-Verwirrungs-Angriffe ab.
• Prüfen, dass aud mit dem Identifier Ihres Services übereinstimmt und iss mit Ihrer erwarteten Issuer-URL.
• exp gegen die aktuelle Zeit prüfen, mit höchstens 60 Sekunden Toleranz für Zeitversatz.
• Bei Schlüsselrotation den öffentlichen Schlüssel per kid aus einem JWKS-Endpunkt nachschlagen; niemals einen einzelnen Schlüssel für immer hardcoden.
• Effektiv widerrufen, indem Sie exp kurz halten (Minuten, nicht Tage), und optional eine jti-Denylist für hochwertige Token pflegen.

Jede etablierte JWT-Bibliothek bietet diese als Optionen in einem einzigen Aufruf an. Wenn Ihr Verifikationscode sie nicht setzt, lassen Sie die Standardwerte aktiv, und Standardwerte waren historisch der Bug. Für das vollständige Bedrohungsmodell siehe unseren Leitfaden zu Sicherheits-Best-Practices.

FAQ

Kann ich einen JWT ohne den geheimen Schlüssel dekodieren?

Ja. Header und Payload sind Base64URL-kodiert, nicht verschlüsselt; jeder, der den Token besitzt, kann seine Claims lesen. Das Geheimnis oder der öffentliche Schlüssel wird nur gebraucht, um die Signatur zu prüfen. Das ist Absicht: Die Payload soll lesbar sein, damit der Empfänger Autorisierungsentscheidungen treffen kann.

Ist es sicher, meinen Produktions-JWT in einen Online-Dekodierer einzufügen?

Nur, wenn der Dekodierer in Ihrem Browser läuft und den Token niemals hochlädt. Unser JWT-Dekodierer parst lokal mit nativem atob und JSON.parse; nichts wird an einen Server gesendet. Remote-Debugger, die Ihren Token per POST an eine API schicken, sollten als Credential-Leak behandelt werden.

Was ist der Unterschied zwischen Dekodieren und Verifizieren eines JWT?

Dekodieren liest nur die Claims; es braucht keinen Schlüssel und beweist nichts. Verifizieren prüft die Signatur gegen den Schlüssel des Issuers und bestätigt, dass der Token nicht manipuliert wurde. Treffen Sie niemals eine Authentifizierungsentscheidung anhand eines dekodierten, aber unverifizierten Tokens.

Mein JWT sieht abgeschnitten aus, was gilt als gültiges Format?

Ein gültiger JWT besteht aus genau drei Base64URL-Segmenten, getrennt durch Punkte: header.payload.signature. Fünf Segmente bedeuten, dass Sie einen verschlüsselten JWT (JWE) haben, keinen JWS. Null Punkte bedeuten, dass Sie nur ein Segment aus einer umbrochenen Terminalzeile kopiert haben.

Warum zeigt der Dekodierer einen abgelaufenen Token weiterhin an?

Ein Dekodierer liest die Claims unabhängig von der Gültigkeit, damit Sie Ablehnungen debuggen können. Nur ein Verifizierer lehnt abgelaufene Token ab. Unser Tool zeigt ein Badge Abgelaufen, indem es exp mit Ihrer lokalen Uhr vergleicht, sodass Sie das Problem sofort erkennen, ohne Unix-Zeitstempel zu entziffern.

Welche Algorithmen kann ich dekodieren?

Alle. Die Dekodierung benötigt nur Base64URL und JSON-Parsing; sie ist algorithmusunabhängig. Dazu gehören HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512, EdDSA und alg:none. Nur die Verifikation hängt vom gewählten Algorithmus ab.

Sollte ich in Node.js jwt-decode oder jsonwebtoken verwenden?

Verwenden Sie jwt-decode im Frontend, wenn Sie nur die Payload lesen müssen, etwa um einen Benutzernamen aus einem Access-Token anzuzeigen. Verwenden Sie jsonwebtoken im Backend, denn nur das Backend darf den Signierschlüssel halten und jwt.verify ausführen. Verifizieren Sie niemals clientseitig.

Fazit

Einen JWT zu dekodieren ist bei Weitem nicht so mysteriös, wie der Begriff “kryptografischer Token” vermuten lässt. Behalten Sie fünf Kernpunkte im Kopf, und Sie stehen nie wieder ratlos vor einer undurchsichtigen eyJhbGciOi…-Zeichenkette:

• Dekodieren ist Base64URL plus JSON-Parsing. Kein Geheimnis nötig.
• Ein JWT hat drei Teile, Header, Payload, Signatur, verbunden durch Punkte.
• Dekodieren beweist niemals Authentizität. Verifizieren Sie immer serverseitig mit dem Schlüssel des Issuers.
• Lehnen Sie alg:none ab und übergeben Sie verify immer eine explizite Algorithmen-Allowlist.
• Speichern Sie niemals Passwörter, private Schlüssel oder sensible PII in der Payload; sie ist für jeden lesbar, der den Token besitzt.

Legen Sie sich unseren kostenlosen JWT-Dekodierer als Lesezeichen für Debugging im Bereitschaftsdienst ab. Token einfügen, Claims lesen, Ablaufzeiten in einer Sekunde erkennen, ohne dass Ihr Token den Browser je verlässt.