Was ist ein JSON Web Token (JWT)?

Ein JSON Web Token (JWT) ist ein standardisiertes Format, um Claims als JSON zwischen Parteien zu übertragen. JWTs werden häufig für Access- und ID-Tokens in APIs, OAuth 2.0 und OpenID Connect eingesetzt. Das Format allein macht eine Anwendung weder zustandslos noch sicher.

Wie ist ein JWT aufgebaut?

Die kompakte Darstellung besteht typischerweise aus drei Base64url-kodierten Teilen: Header, Payload und Signatur, getrennt durch Punkte. Der Header benennt etwa Algorithmus und Schlüssel-ID. Der Payload enthält Claims wie Aussteller (iss), Empfänger (aud), Subjekt (sub) und Ablaufzeit (exp). Die Signatur schützt bei einem JWS die Integrität von Header und Payload.

Sind JWTs verschlüsselt?

Meist nicht. Base64url ist nur eine Kodierung; jeder Tokeninhaber kann Header und Payload lesen. Ein signiertes JWS verhindert unbemerkte Manipulation, aber keine Einsicht. Verschlüsselte JWTs verwenden JWE, sind jedoch seltener. Sensible Daten gehören grundsätzlich nur dann in ein Token, wenn Offenlegung, Protokollierung und lange Kopien ausdrücklich berücksichtigt wurden.

Wofür werden JWTs verwendet?

Welche JWT-Schwachstellen gibt es?

• Die Anwendung dekodiert das Token, verifiziert die Signatur aber nicht zuverlässig.
• Unerwartete oder unsichere Algorithmen werden akzeptiert, einschließlich Algorithmusverwechslung.
• Schwache HMAC-Geheimnisse lassen sich offline erraten.
• kid, jku oder eingebettete Schlüssel beeinflussen unkontrolliert die Schlüsselauswahl.
• iss, aud, exp, nbf oder Token-Typ werden nicht geprüft.
• Tokens gelangen in URLs, Logs, Browser-Speicher oder an den falschen Dienst.
• Lange Laufzeiten und fehlender Widerruf verlängern die Wirkung eines Diebstahls.

Wie verwendet man JWTs sicher?

Eine gepflegte Bibliothek muss mit fest vorgegebenem Algorithmus verifizieren. Schlüssel werden ausreichend stark erzeugt, getrennt verwaltet, rotiert und über vertrauenswürdige Metadaten bezogen. Aussteller, Empfänger, Zeitangaben, erlaubte Nutzung und Signatur werden gemeinsam geprüft. Access Tokens bleiben kurzlebig; Refresh Tokens erhalten Rotation und Wiederverwendungserkennung. Autorisierung erfolgt weiterhin serverseitig für jedes Objekt und jede Funktion.

Codebeispiel: Dekodieren ist keine Verifikation

Verwundbares Pseudocode-Beispiel:

claims = base64url_decode(token.payload)
currentUser = claims.sub

Sicherer Ablauf:

claims = verifyJwt(token, {
  algorithms: ['RS256'],
  issuer: 'https://identity.example',
  audience: 'orders-api',
  requiredClaims: ['sub', 'exp', 'iat']
})

currentUser = loadActiveUser(claims.sub)

Die konkrete Bibliotheks-API unterscheidet sich, die Sicherheitsentscheidung nicht: Algorithmus, Schlüssel, Aussteller, Empfänger, Zeitangaben und Token-Typ werden gemeinsam geprüft. Rollen im Token dürfen außerdem nicht dauerhaft eine aktuellere serverseitige Berechtigungsentscheidung ersetzen.

JWT oder klassische Session?

JWTs sind nützlich, wenn mehrere Dienste standardisierte, überprüfbare Claims benötigen. Eine serverseitige Session ist häufig einfacher zu widerrufen und hält Berechtigungsdaten zentral aktuell. Wer nur eine klassische Webanmeldung umsetzt, gewinnt durch JWT nicht automatisch Sicherheit oder Skalierbarkeit. Die Wahl sollte aus Architektur und Bedrohungsmodell folgen, nicht aus dem Wunsch nach einem modischen Format.