JWT lesen & verstehen — dambmann.cloud

Worum geht’s

JSON Web Tokens (JWT) begegnen dir überall: Login-Sessions, API-Zugriffe, OAuth/OIDC. Wenn ein Nutzer „nicht authentifiziert” gemeldet wird oder eine API 401 liefert, musst du den Token lesen können: Wer hat ihn ausgestellt, für wen gilt er, wann läuft er ab? Dieser Skill zeigt den Aufbau und das sichere Lesen — und die wichtige Grenze: Lesen ist nicht Verifizieren.

Konzept

Ein JWT besteht aus drei Base64url-Teilen, getrennt durch Punkte: header.payload.signature.

Header: JSON mit alg (Signatur-Algorithmus, z. B. RS256, HS256) und typ (JWT).
Payload: JSON mit den Claims. Wichtige Standard-Claims:
- iss (Issuer/Aussteller), sub (Subject/Subjekt), aud (Audience/Zielgruppe),
- exp (Ablaufzeit als Unix-Timestamp), iat (ausgestellt am), nbf (nicht vor).
Signatur: schützt Header + Payload gegen Veränderung. Bei HS256 mit einem geteilten Geheimnis (HMAC), bei RS256 mit einem privaten Schlüssel (asymmetrisch, Prüfung mit öffentlichem Schlüssel).

Entscheidend: Header und Payload sind nur Base64url-kodiert, nicht verschlüsselt. Jeder kann sie lesen — schreibe also nie Geheimnisse (Passwörter, Schlüssel) in einen JWT. Ein Decoder zeigt dir Header und Payload im Klartext, ohne die Signatur zu prüfen. Ob der Token gültig ist (Signatur korrekt, nicht abgelaufen), entscheidet erst die serverseitige Verifikation gegen den richtigen Schlüssel.

Ein JWT besteht aus drei Base64url-Teilen — Header, Payload, Signatur:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Ik1heCBNdXN0ZXJtYW5uIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzAwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header — Algorithmus & Typ

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

Payload — Claims (Inhalt)

{
  "sub": "1234567890",
  "name": "Max Mustermann",
  "role": "admin",
  "iat": 1700000000
}

Signature

HMAC/RSA über Header.Payload mit dem Server-Schlüssel. Nur damit lässt sich Echtheit prüfen — der Decoder liest sie nicht nach.

Base64url ist nur Kodierung, keine Verschlüsselung: Header und Payload sind für jeden lesbar. Niemals Geheimnisse in den Payload schreiben.

Beispiel-Fall

Aufgabe: Eine API antwortet mit 401, der Client schickt aber einen Bearer-Token. Du sollst prüfen, woran es liegt.

Token kopieren und im Decoder die drei Teile entschlüsseln.
Payload prüfen: exp als Unix-Timestamp in ein Datum umrechnen → liegt es in der Vergangenheit? Dann ist der Token abgelaufen (häufigste 401-Ursache).
aud prüfen: Passt die Audience zur aufgerufenen API? Ein für eine andere API ausgestellter Token wird abgelehnt.
iss prüfen: Stammt der Token vom erwarteten Identity-Provider?
Ergebnis dokumentieren — aber nie aus dem Decoder schließen, der Token sei „gültig”: Das entscheidet nur die Signaturprüfung auf dem Server.

Anwenden

▶ Am Tool ausprobieren

Beachte: Der Decoder prüft keine Signatur — er zeigt nur den (lesbaren) Inhalt.

Füge einen JWT ein und lies Header (alg, typ) und Payload getrennt.
Suche im Payload nach exp und rechne den Unix-Timestamp in ein Datum um.
Vergleiche iss und aud mit den erwarteten Werten deiner Anwendung.

Tool öffnen: /jwt-decoder ↗

Selbsttest

Praxis-Challenge

⚑ Praxis-Challenge

Dekodiere einen JWT (z. B. von jwt.io als Beispiel) und beantworte schriftlich: Wer ist Issuer und Audience, wann läuft der Token ab und welcher Signatur-Algorithmus wird im Header genannt? Erkläre in einem Satz, warum der Decoder dir nicht sagen kann, ob der Token gültig ist.

Tool öffnen: /jwt-decoder ↗