JSON Web Tokens erklärt

JWTs stecken in fast jeder modernen Anmeldung und API. Dieser Ratgeber erklärt Aufbau, Lesen und sicheren Einsatz.

Tool öffnen: JWT-Decoder

Die drei Teile

Ein JWT sieht aus wie xxxxx.yyyyy.zzzzz. Der erste Teil ist der Header, ein JSON-Objekt mit Algorithmus (alg) und Typ (typ). Der zweite Teil ist der Payload mit den Claims. Der dritte Teil ist die Signatur über die ersten beiden Teile, erstellt mit einem Secret oder privaten Schlüssel. Jeder Teil ist Base64url-kodiert und damit sicher in URLs und HTTP-Headern.

Registrierte Claims

  • iss (Aussteller): wer das Token erstellt und signiert hat.
  • sub (Subjekt): Nutzer oder Dienst, um den es geht.
  • aud (Zielgruppe): welche Anwendung es akzeptieren soll.
  • exp (Ablaufzeit): wann das Token ungültig wird.
  • nbf (nicht vor): ab wann es gültig ist.
  • iat (ausgestellt am): wann es erstellt wurde.
  • jti (JWT-ID): eine eindeutige ID gegen Wiederverwendung.

Access-Tokens und ID-Tokens

In OpenID Connect sagt ein ID-Token der Client-Anwendung, wer sich angemeldet hat, und enthält Profil-Claims wie Name und E-Mail. Ein Access-Token wird an eine API geschickt und zeigt, was der Aufrufer darf, oft mit einem scope-Claim. Access-Tokens sollten kurzlebig sein, meist Minuten bis eine Stunde, und per Refresh-Token erneuert werden.

Fehler, die du vermeiden solltest

  • Ein Token nur dekodieren, nicht prüfen, und den Claims trotzdem vertrauen.
  • Den Algorithmus aus dem Token übernehmen statt den, den dein Server erwartet.
  • Ein kurzes, erratbares HMAC-Secret verwenden. Nimm mindestens 32 zufällige Bytes.
  • Sensible Daten im Payload speichern.
  • Tokens ohne Ablauf oder sehr langlebige Access-Tokens ausstellen.