Was ist ein JSON Web Token (JWT)?

Ein JSON Web Token ist ein kompaktes, URL-sicheres Token mit signierten JSON-Claims, mit dem Server Anfragen ohne gespeicherte Sessions prüfen. So beschreibt es auch RFC 7519 selbst – als kompaktes, URL-sicheres Mittel, Claims zwischen zwei Parteien zu übertragen –, und die beiden Gedanken darin tragen alles Weitere: Das Token enthält seine Fakten, und eine Signatur macht diese Fakten für jeden prüfbar, der den richtigen Schlüssel hat, ohne dass eine Datenbank beteiligt ist.

Das Wichtigste in Kürze

Ein JWT, decodiert

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJzdWIiOiJ1c3ItOGZrMiIsInJvbGUi… . dBjftJeZ4CVP…

header     { "alg": "HS256", "typ": "JWT" }
payload    { "sub": "usr-8fk2",  "role": "editor",
             "iss": "https://api.example.com",  "aud": "example-web",
             "iat": 1767024900,  "exp": 1767025800 }        ← 15 Minuten Lebensdauer
signature  HMACSHA256( base64url(header) + "." + base64url(payload), secret )

Jeder kann die ersten beiden Teile DECODIEREN – Base64Url ist Verpackung, keine Verschlüsselung.
Nur Schlüsselinhaber können den dritten FÄLSCHEN – und genau darin liegt der ganze Kniff.

Der Kontrast, den es sich im Code anzusehen lohnt – die zustandsbehaftete Alternative, an der sich jede JWT-Entscheidung messen lassen muss:

// JavaScript / Node.js — Back4app JS SDK
// The stateful contrast: Back4app issues revocable session tokens
const user = await Parse.User.logIn('ada', 'correct-horse-battery');
const token = user.getSessionToken(); // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
await Parse.User.logOut(); // token invalid NOW — no waiting for an exp claim

// Flutter / Dart — Back4app Flutter SDK
// The stateful contrast: Back4app issues revocable session tokens
final user = ParseUser('ada', 'correct-horse-battery', null);
await user.login();
final token = user.sessionToken; // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
await user.logout(); // token invalid NOW — no waiting for an exp claim

// iOS / Swift — Back4app Swift SDK
// The stateful contrast: Back4app issues revocable session tokens
let user = try await User.login(username: "ada", password: "correct-horse-battery")
let token = user.sessionToken // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
try await User.logout() // token invalid NOW — no waiting for an exp claim

// Android / Kotlin — Back4app Android SDK
// The stateful contrast: Back4app issues revocable session tokens
val user = ParseUser.logIn("ada", "correct-horse-battery")
val token = user.sessionToken // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
ParseUser.logOut() // token invalid NOW — no waiting for an exp claim

Wie die Prüfung funktioniert

Die Präzision, die viele Erklärungen auslassen: “JWT” bezeichnet das Claims-Format; was tatsächlich alle herumreichen, ist ein JWS (RFC 7515) – die signierte Serialisierung –, während JWE das verschlüsselte Geschwister für Payloads ist, die unlesbar bleiben müssen. Und die Prüfung besteht aus zwei Aufgaben, nicht aus einer: erst die Signatur prüfen, dann die Claims validieren – exp und nbf gegen die Uhr, iss gegen Ihre Allowlist vertrauenswürdiger Aussteller, aud gegen die Kennung dieses Dienstes. Ein einwandfrei signiertes Token, das abgelaufen ist, vom falschen Aussteller stammt oder für eine andere Zielgruppe ausgestellt wurde, ist ein einwandfrei signierter Angriff.

Claims: das Vokabular des Payloads

Halten Sie Payloads aus zwei Gründen schlank: Tokens reisen bei jeder Anfrage als Header mit (Cookies sind auf etwa 4 KB begrenzt, und jeder Claim ist wiederholte Bandbreite), und alles darin ist für jeden lesbar, der das Token besitzt.

JWT vs. Session-Tokens

Die unmoderne Wahrheit, mit der inzwischen mehrere Best-Practice-Leitfäden beginnen: Für eine serverseitig gerenderte App mit einem einzigen Backend sind Framework-Sessions einfacher und besser kontrollierbar – JWTs lohnen sich, wenn Tokens über Dienste hinweg geprüft werden müssen oder von Parteien, die nicht bei jeder Anfrage beim Aussteller nachfragen sollen.

Das Widerrufsproblem, ehrlich betrachtet

Zustandslosigkeit ist die Unfähigkeit zu widerrufen – dieselbe Eigenschaft, zweimal beschrieben. Ein signiertes Token ist bis exp gültig, egal was seitdem passiert ist: Abmeldung, Passwortänderung, Kontosperre. Jede Lösung führt wieder Zustand ein, also wählen Sie die Variante: eine Denylist über jti + iss (die von OWASP empfohlene Konstruktion), bei jeder Anfrage geprüft – wenig Zustand, aber Zustand; Schlüsselversionierung, die alle auf einmal widerruft; oder die Standardarchitektur – kurzlebige Access Tokens (5–15 Minuten) plus widerrufbare Refresh Tokens mit Rotation: Jede Erneuerung stellt ein neues Refresh Token aus und zieht das alte zurück, sodass ein gestohlenes beim ersten erneuten Einsatz stirbt, und die Wiederverwendung eines zurückgezogenen Tokens meldet den Diebstahl und entwertet die gesamte Token-Familie. Die Widerrufslatenz entspricht dann der Lebensdauer des Access Tokens – der eigentliche Grund, warum diese Lebensdauern kurz sind.

Einen Algorithmus wählen – und die Angriffe auf diese Wahl

Der Angriffsteil, für den es RFC 8725 gibt, in drei Sätzen. alg: "none" ist ein zulässiger Header-Wert – Bibliotheken, die ihn respektieren, akzeptieren unsignierte Tokens. Der Confusion-Angriff: Einem Prüfer, der den Header des Tokens den Algorithmus wählen lässt, kann man ein “HS256”-Token unterschieben, das mit dem öffentlichen RSA-Schlüssel des Servers als HMAC-Geheimnis signiert wurde – ein öffentlicher Wert, als privater benutzt. Beide Angriffe scheitern an derselben Maßnahme: Der Prüfer legt die akzeptierten Algorithmen und Schlüssel in der Konfiguration fest und überlässt die Wahl nie dem Header.

Wo JWTs im Browser gespeichert werden

Das Bedrohungsmodell, nicht die Folklore: localStorage tauscht CSRF-Immunität gegen XSS-Diebstahl, Cookies tauschen umgekehrt – deshalb teilt der Konsens das Paar auf: Access Token im Arbeitsspeicher, Refresh Token in einem gehärteten Cookie.

Typische Anwendungsfälle

• API-Authentifizierung – das Bearer Token hinter Authorization-Headern bei REST- und GraphQL-APIs.
• Identität zwischen Microservices – ein vom Gateway ausgestelltes Token, das jeder Dienst unabhängig prüft, ohne gemeinsamen Session-Speicher.
• ID Tokens von OpenID Connect – die signierte Identitätszusicherung hinter jedem Social Login – immer ein JWT.
• Übergaben zwischen Systemen – signierte Links, Webhook-Payloads, Download-Freigaben: Claims, die eine Partei prüft, die bei Ihnen nicht zurückfragen kann.
• Zustandslose Autorisierungshinweise – Rollen und Tenant-IDs in Claims, wobei die maßgebliche Prüfung weiterhin serverseitig stattfindet.

Sollten Sie JWTs oder Sessions verwenden? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Unwiderrufbarkeit ist strukturell. Jede Abhilfe – Denylists, kurze Lebensdauern, Rotation – holt einen Teil des Zustands zurück, den Sie entfernt haben; kalkulieren Sie das ein, bevor Sie sich für Zustandslosigkeit entscheiden.
• Claims veralten. Rollen sind eine Momentaufnahme bei der Ausstellung; ein herabgestufter Admin bleibt bis zum Ablauf Admin. Kurze Lebensdauern begrenzen dieses Fenster.
• Der Payload ist öffentlich. Behandeln Sie ihn als lesbar für den Nutzer und jeden Token-Dieb – Kennungen ja, Geheimnisse und personenbezogene Daten nein.
• Bibliotheks-Standardwerte haben schon Schaden angerichtet. Festgelegte Algorithmen, Claim-Validierung und typ-Prüfung liegen in Ihrer Konfigurationsverantwortung, nicht in den Garantien der Bibliothek.
• Größe summiert sich. Jeder Claim reist bei jeder Anfrage mit; großzügige Payloads belasten mobile Bandbreite und können Cookie-Grenzen sprengen.

Tokens mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die Wahl der Plattform selbst illustriert die Entscheidungsmatrix: Client-Sessions nutzen widerrufbare, serverseitige Session-Tokens – die Code-Tabs oben –, sodass Abmeldung, Passwortänderungen und das Beenden von Sessions im Dashboard sofort wirken, ohne dass ein Ablauffenster abgewartet werden muss. JWTs erscheinen dort, wo sie hingehören: Die OIDC-ID-Tokens von Identity Providern werden beim Social Login serverseitig von Auth-Adaptern geprüft, und Cloud-Code-Funktionen können mit Standardbibliotheken JWTs für Übergaben an Dritte ausstellen oder prüfen – mit dem Signaturgeheimnis in der serverseitigen Konfiguration, niemals an Clients ausgeliefert. Zustandsbehaftet, wo Kontrolle zählt, zustandslos an den Rändern, wo die Prüfung reisen muss: die Architektur, für die dieser Artikel plädiert, fertig zusammengesetzt.