JSON Web Tokens verstehen – Aufbau, Risiken, Best Practices

Ein Login ist umgesetzt, die API ist geschützt – und jetzt sollen mehrere Services, Mobile-Apps oder ein SPA (Single Page Application) darauf zugreifen. In vielen Projekten fällt dann schnell das Schlagwort JWT. Gemeint sind kleine Tokens, die sich leicht übertragen lassen und auf den ersten Blick serverseitige Sessions ersetzen können.

Damit das nicht in Sicherheitsproblemen endet, hilft ein klares Bild: Was steckt im Token, was wird wirklich geprüft, was darf niemals im Token landen – und wo passen klassische Sessions besser? Genau darum geht es hier.

Was ein JWT ist – und was nicht

Token statt Session: die Grundidee

Ein JSON Web Token ist ein kompakter String, der bestimmte Informationen (Claims) enthält und kryptografisch signiert ist. „Signiert“ heißt: Der Server kann später prüfen, ob das Token unverändert ist und wirklich von ihm stammt. Das Token wird typischerweise im Authorization Header als Bearer Token gesendet.

Wichtig: Ein JWT ist nicht automatisch „verschlüsselt“. Standardmäßig ist es nur signiert. Das bedeutet: Der Inhalt ist lesbar (Base64URL-kodiert), aber Manipulationen werden erkannt. Wer Vertraulichkeit braucht, muss zusätzlich verschlüsseln (oder sensible Daten gar nicht erst hineinpacken).

Warum Teams JWT mögen

• Ein Token passt gut zu APIs und Microservices, weil es sich leicht zwischen Systemen weiterreichen lässt.
• Der Server muss nicht zwangsläufig Session-Daten speichern (weniger State auf dem Server).
• Claims können Rollen oder Berechtigungen transportieren – solange sie gut gepflegt und kurzlebig sind.

Aufbau eines JWT: Header, Payload, Signature

Die drei Teile kurz erklärt

Ein JWT besteht aus drei durch Punkte getrennten Teilen:

• Header: Enthält Metadaten, z. B. den Typ (JWT) und den Signaturalgorithmus.
• Payload: Enthält Claims, z. B. Nutzer-ID, Rollen, Ablaufzeit.
• Signature: Die Signatur über Header+Payload mit einem Secret (HMAC) oder einem privaten Schlüssel (RSA/ECDSA).

Die Payload ist Base64URL-kodiert, aber nicht geheim. Daher gilt als Faustregel: Alles, was nicht im Browser-Storage „öffentlich“ liegen dürfte, gehört auch nicht in ein JWT.

Welche Claims üblich sind

Typisch sind:

• exp (Expiration Time): Ablaufzeitpunkt. Ohne kurze Laufzeit werden Tokens schwer widerrufbar.
• iat (Issued At): Ausstellungszeit.
• sub (Subject): Subjekt, oft die User-ID.
• aud (Audience): Für wen das Token gedacht ist (z. B. „api“).
• iss (Issuer): Wer es ausgestellt hat (z. B. Auth-Service).

Gerade aud und iss helfen, Tokens nicht versehentlich in falschen Kontexten zu akzeptieren.

Typische Risiken: Wo JWT-Setups in der Praxis kippen

„JWT ist sicher“ – aber der Storage ist es nicht

Ein häufiges Problem ist nicht die Kryptografie, sondern die Ablage im Client. Wenn ein Token in localStorage gespeichert wird, kann es bei XSS (Cross-Site Scripting) ausgelesen und missbraucht werden. Ein gestohlenes Token ist in vielen Setups wie ein gestohlenes Passwort – nur schneller verwertbar.

Wenn Cookies genutzt werden, muss CSRF (Cross-Site Request Forgery) bedacht werden. Dazu passen gut CSRF Schutz im Web – Formulare und APIs richtig absichern und HTTP Cookies verstehen – Session, SameSite und Sicherheit.

Widerruf ist nicht „eingebaut“

Bei klassischen Sessions kann ein Server eine Session sofort invalidieren. Bei JWT ist das schwieriger, weil ein bereits ausgegebenes Token bis zum Ablauf gültig bleibt – solange die Signatur stimmt. Das ist kein Bug, sondern das Konzept.

Lösungsansätze sind:

• Sehr kurze Access-Token-Laufzeiten und Refresh-Token mit separater Verwaltung.
• Eine Sperrliste (Blacklist) – die aber wieder State auf dem Server bedeutet.
• „Token Versioning“: eine serverseitige Version pro Benutzer, die im Token als Claim steckt (bei Logout wird die Version erhöht).

Zu viele Daten im Token

JWT werden gern überladen: komplette Profile, E-Mail, Adressen, Feature-Flags, Rechtebäume. Das macht Tokens groß, erhöht das Risiko von Datenleaks und führt zu Inkonsistenzen (Daten ändern sich, Token bleibt alt). Besser: nur stabile Identifikatoren und wenige, wirklich benötigte Claims.

Algorithmus- und Prüf-Fallen

In sicheren Libraries ist vieles gelöst, aber Fehlkonfigurationen passieren:

• Der Server muss den erwarteten Algorithmus fest konfigurieren (nicht „aus dem Token übernehmen“).
• iss und aud sollten geprüft werden, wenn mehrere Aussteller oder Zielsysteme existieren.
• Uhrzeit-Drift berücksichtigen (kleine Toleranz), aber nicht zu großzügig werden.

Wann JWT sinnvoll sind – und wann Sessions besser passen

Eine schnelle Entscheidungshilfe

• Wenn mehrere APIs/Services ein Token prüfen sollen, ohne jedes Mal die Session im zentralen Store nachzuschlagen
  • dann passt JWT oft gut (mit kurzen Laufzeiten und sauberem Refresh-Flow).
• Wenn ein klassisches Web-Frontend serverseitig gerendert ist und vor allem „Browser + Cookies“ genutzt werden
  • dann sind serverseitige Sessions häufig einfacher, weil Logout/Widerruf klarer ist.
• Wenn sehr strikte Anforderungen an sofortigen Widerruf bestehen (z. B. Admin-Zugriffe)
  • dann sind Sessions oder ein hybrider Ansatz oft die bessere Wahl.

Ein häufiger Hybrid: Access Token + Refresh Token

In vielen modernen Setups gibt es zwei Token-Typen:

• Access Token: kurzlebig, wird an APIs gesendet.
• Refresh Token: langlebiger, wird genutzt, um neue Access Tokens zu holen; sollte strenger geschützt und serverseitig verwaltet werden (Rotation, Sperrung).

Das reduziert den Schaden bei Diebstahl und macht Logout realistischer, weil Refresh Tokens serverseitig invalidiert werden können.

Praktische Umsetzung: Validierung, Speicherung, Ablauf

Was auf dem Server bei jeder Anfrage geprüft werden sollte

Eine robuste Prüfung besteht nicht nur aus „Signatur korrekt“:

• Signatur validieren und Algorithmus fest vorgeben.
• Ablaufzeit (exp) prüfen.
• Aussteller (iss) und Audience (aud) prüfen, wenn relevant.
• Optional: Nutzerstatus prüfen (z. B. gesperrt) oder Token-Version vergleichen, wenn Widerruf wichtig ist.

Für API-Fehler lohnt sich eine konsistente Antwortstrategie. Dazu passt API-Fehler richtig behandeln – robuste Webanwendungen Schritt für Schritt.

Wo das Token im Frontend am wenigsten Ärger macht

Es gibt keine universelle Antwort, aber klare Trade-offs:

Eine kurze Schrittfolge für ein solides Setup

• Access Tokens kurzlebig halten und konsequent über den Authorization-Header senden.
• Refresh Tokens serverseitig verwalten (Rotation) und bei Logout/Passwortwechsel ungültig machen.
• Token-Inhalt minimal halten: User-ID, Aussteller, Audience, Ablauf, evtl. Rolle – keine Profile.
• Validierung serverseitig vollständig: Signatur, exp, iss, aud; keine „teilweisen“ Checks.
• Client-Storage bewusst wählen (Cookie vs Memory) und XSS/CSRF als Gesamtpaket betrachten.

Häufige Fragen aus Projekten

Sollten Rollen und Rechte im Token stehen?

Rollen können funktionieren, wenn sie stabil sind und sich selten ändern. Wenn Berechtigungen oft angepasst werden oder sofort wirken müssen, ist ein serverseitiger Check pro Request (oder pro „Session“) meist zuverlässiger. Sonst bleibt das Token „alt“, bis es erneuert wird.

Kann ein JWT „invalid“ werden, bevor es abläuft?

Von allein nicht. Frühzeitiger Widerruf braucht zusätzliche Mechanismen, zum Beispiel Refresh-Token-Invalidierung, eine Sperrliste oder eine Token-Version, die serverseitig geprüft wird.

Ist ein JWT dasselbe wie eine sichere Anmeldung?

Nein. JWT ist ein Transport- und Prüfmechanismus für Identität/Claims. Die Sicherheit hängt stark von Login-Prozess, Storage, HTTPS, XSS-Schutz, CSRF-Strategie und Validierungsregeln ab. Für saubere Client-Server-Abgrenzung hilft auch HTTP-Request-Header verstehen – wichtige Felder im Alltag.

Passt JWT zu Mobile Apps und SPAs?

Oft ja, weil APIs im Vordergrund stehen. Trotzdem bleibt der wichtigste Punkt: Token-Diebstahl verhindern und Tokens kurzlebig machen. „Bequem dauerhaft eingeloggt“ ist ein UX-Ziel, das über Refresh Tokens und serverseitige Kontrolle umgesetzt werden sollte, nicht über sehr lange Access Tokens.