Was ist ein JSON Web Token (JWT)?

JWT in einem Satz

Ein JSON Web Token (JWT, ausgesprochen "jot", RFC 7519) ist ein kompaktes, URL-sicheres Format, um signierte oder verschlüsselte Aussagen ("Claims") zwischen zwei Parteien zu transportieren. Praktisch fast immer: ein signiertes Token, das einem Server beweist, dass ein anderer Server bestimmte Aussagen über einen Nutzer gemacht hat - und dass diese Aussagen seitdem nicht verändert wurden.

Wofür JWTs verwendet werden

• Auth-Tokens in OAuth-2.0- und OpenID-Connect-Flows (mit Abstand häufigster Einsatz)
• API-Keys mit eingebetteten Berechtigungen (Stateless-Authorization)
• ID-Tokens in OIDC: Auth-Provider beweist Backend, wer der Nutzer ist
• Magic-Link-Tokens für Passwort-lose Logins (kurze Lifetime, einmalig nutzbar)
• Service-to-Service-Auth in Microservices, mit kurzer Lifetime und engem Scope

Wofür JWTs NICHT gedacht sind

JWTs sind kein Allheilmittel. Drei Anti-Patterns sind verbreitet:

• Klassische Server-Sessions ersetzen, wenn man eigentlich gar keinen Stateless-Vorteil braucht. Eine SQL-Datenbank mit Session-Tabelle ist oft die einfachere Lösung.
• Sensible Daten im Payload: der Payload ist NICHT verschlüsselt, nur base64url-encoded. Jeder mit Token-Zugriff sieht den Inhalt - siehe die Decode-Funktion auf jwtdecoder.de.
• Lange Lifetimes (Stunden bis Tage): JWTs lassen sich nicht ohne Weiteres revozieren. Sobald ein Token ausgegeben ist, ist es bis exp gültig - kompromittierte Tokens bleiben gefährlich.

Welches Problem JWTs lösen

Vor JWT war die Standard-Lösung: User loggt sich ein, Server speichert Session-ID in einer Datenbank, schickt opake Cookie zurück. Bei jedem Request: Cookie-Lookup gegen DB. Funktioniert gut, hat aber zwei Schwächen:

1. Skalierung über Service-Grenzen: wenn Service B die Session von Service A prüfen will, muss B entweder A's DB lesen oder A pro Request fragen.
2. Mobile-Clients: Cookies sind im Mobile-App-Kontext lästig (kein automatisches Cookie-Handling wie im Browser).

JWT löst beides: der Token enthält alle nötigen Aussagen, signiert vom Issuer. Jeder Service, der den Public Key kennt, kann das Token verifizieren - ohne Rückfrage beim Issuer, ohne gemeinsame DB.

Was im Token drinsteht

Ein typisches Access-Token aus einem OAuth-Flow:

{
  "iss": "https://auth.example.com",
  "sub": "user_42",
  "aud": "https://api.example.com",
  "exp": 1736245890,
  "iat": 1736242290,
  "scope": "read:profile write:profile"
}

Was die Felder bedeuten: siehe Standard-Claims-Ratgeber. Im Kern: das Token sagt "der Issuer auth.example.com bestätigt, dass User user_42 bis exp gegen die API api.example.com zugreifen darf, mit den genannten Scopes".

Wann JWT die richtige Wahl ist

Daumenregel: wenn dein System aus mehr als einem Service besteht UND die Services unabhängig deployen wollen UND du Mobile-Clients hast, ist JWT meist die richtige Wahl. Wenn du einen Monolithen hast und Logout-Latenz von Stunden inakzeptabel ist (Banking, Healthcare), bleib bei klassischen Sessions.

Weiterführend

Das jwtdecoder.de-Tool zerlegt jedes Token live in Header, Payload und Signatur. Für die Verifikation mit Secret oder Public Key brauchst du den entsprechenden Schlüssel - alles passiert im Browser, kein Server-Upload. Mehr zum JWT-Aufbau und zu den Signatur-Algorithmen in den entsprechenden Ratgebern.