Was ist ein JWT-Token? Erklärung, Funktion & OAuth-Vergleich

Wer mit APIs oder modernen Webanwendungen arbeitet, stößt früher oder später auf JWTs – oft ohne zu wissen, was sich hinter dem Kürzel verbirgt. Dabei ist das Prinzip erstaunlich simpel: Ein JWT überträgt Informationen als signiertes JSON-Objekt, das kryptographisch signiert ist und sich daher ohne Datenbankabfrage verifizieren lässt. Dieser Artikel erklärt, wie JWT funktioniert, wo es sich von OAuth unterscheidet, und welche Stolperfallen Entwickler kennen sollten.

Offener Standard: RFC 7519 · Payload-Format: JSON · Struktur: Header.Payload.Signature · Top-Quelle: jwt.io

Was ist ein JWT-Token?

Ein JWT (JSON Web Token) ist ein kompaktes, selbstenthaltendes Format zur sicheren Übertragung von Claims als JSON-Objekt mit kryptographischer Signatur. Der offizielle Standard RFC 7519 stammt von der IETF und wurde im Mai 2015 veröffentlicht.

Die Struktur besteht aus drei Teilen, die durch Punkte getrennt und jeweils Base64-kodiert sind:

Definition nach RFC 7519

RFC 7519 definiert JWT als kompaktes, URL-sicheres Mittel zur Übertragung von Ansprüchen (Claims) zwischen zwei Parteien. Die Claims sind JSON-Daten, die Informationen über einen Nutzer oder eine Anfrage enthalten.

Struktur: Header, Payload, Signature

Der Header enthält Metadaten wie den verwendeten Algorithmus (z.B. RS256 oder HS256) und den Tokentyp. Der Payload speichert die eigentlichen Claims wie sub (Subject), name, iat (Issued At), exp (Expiration) und aud (Audience). Die Signatur wird mit einem geheimen Schlüssel oder einem privaten Schlüssel erzeugt und ermöglicht die Überprüfung der Datenintegrität.

JWT ist ein in sich geschlossenes, kompaktes Format, um Informationen als JSON-Objekt auszutauschen. — oose.de (Technischer Blog)

Was macht ein JWT-Token?

JWT ermöglicht die sichere Übermittlung von Informationen zwischen Client und Server, ohne dass der Empfänger bei jeder Anfrage eine Datenbankabfrage durchführen muss. Der Ressourcenserver validiert die Signatur lokal und extrahiert die Claims direkt aus dem Token.

Funktion in der Authentifizierung

In der Praxis funktioniert JWT-Authentifizierung so: Nach dem Login erhält der Client ein signiertes Token, das er bei jeder Anfrage im Authorization-Header mitschickt (Bearer-Token). Der Server prüft die Signatur und die Claims – insbesondere exp und aud – bevor er Zugriff gewährt.

Übertragung zwischen Client und Server

Ein typischer Ablauf: Der Client sendet Anmeldedaten an den Server. Dieser generiert ein JWT mit den erforderlichen Claims und signiert es. Bei jeder subsequenten Anfrage sendet der Client das JWT im Header:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Wichtig: Der Payload ist Base64-kodiert, aber nicht verschlüsselt. Sensible Daten wie Passwörter oder Gesundheitsdaten gehören nicht in ein JWT.

Was ist der Unterschied zwischen JWT und OAuth?

OAuth 2.0 ist ein Autorisierungs-Framework, das definiert, wie Zugriff erteilt wird – aber kein spezifisches Token-Format vorgibt. JWT hingegen ist ein Datenformat, das Claims transportiert. Die beiden ergänzen sich häufig, sind aber grundverschieden konzipiert.

Die zwei Technologien lassen sich kombinieren: In OAuth-Flows wird oft ein JWT als Access-Token oder ID-Token verwendet. OpenID Connect erweitert beispielsweise OAuth 2.0 und nutzt JWT als ID-Token für Benutzerinformationen – ID-Tokens in OIDC sind immer JWTs.

OAuth 2.0 definiert, wie Tokens erhalten und verwendet werden. JWT definiert, wie ein Token aussieht und wie es Informationen enthält. — Logto Blog (Authentifizierungs-Experte)

JWT als Token-Format

JWT spezifiziert ausschließlich die Struktur und das Format eines Tokens. Ein JWT kann eigenständig für einfache API-Authentifizierung verwendet werden, ohne dass ein vollständiger OAuth-Flow implementiert wird.

OAuth als Autorisierungs-Framework

OAuth 2.0 definiert mehrere Flows (Authorization Code, Resource Owner Password Credentials etc.) und bietet scope-basierte Zugriffssteuerung sowie Token-Revocation. Für die Integration von JWT in OAuth-Flows existiert z.B. das JWT for OAuth Client Authorization Grants Feature bei IBM.

Wie generiert und verwendet man ein JWT-Token?

Die Generierung eines JWT erfolgt in mehreren Schritten: Zuerst wird der Header als JSON erstellt und Base64-kodiert. Dann folgt der Payload mit den gewünschten Claims. Abschließend werden beide Teile mit dem Secret oder privaten Schlüssel signiert und mit Punkten verbunden.

Generierungsschritte

1. Header erstellen: {"alg":"HS256","typ":"JWT"} → Base64URL-kodieren
2. Payload erstellen mit Claims: {"sub":"123","name":"Max Mustermann","iat":1516239022,"exp":1516242622} → Base64URL-kodieren
3. Signatur erzeugen mit Secret: HMACSHA256(header + "." + payload, secret)
4. Teile verbinden: header.payload.signature

Verwendung als Bearer-Token

Nach der Generierung wird das JWT als Bearer-Token im HTTP-Header übermittelt. Der Server extrahiert den Header, validiert die Signatur und prüft die Claims – insbesondere iss, aud, exp und nbf – bevor die Anfrage autorisiert wird.

Warum empfehlen viele JWT nicht?

Trotz seiner Verbreitung hat JWT mehrere Fallstricke, die immer wieder zu Sicherheitsvorfällen führen. OWASP empfiehlt explizite Algorithmen und Claims-Validierung als Mindeststandard.

Häufige Kritikpunkte

• alg: none: Die Akzeptanz des unsignierten „none”-Algorithmus bricht die gesamte Sicherheit und ermöglicht Tokens ohne gültige Signatur.
• Fehlende exp-Validierung: Ohne Prüfung des Ablauf-Claims bleiben Tokens nach einer Kompromittierung dauerhaft gültig.
• Fehlende aud-Validierung: Das Token könnte für einen anderen Dienst bestimmt sein und trotzdem akzeptiert werden.
• Schwache Secrets: Einfache Passwörter für HS256-Signaturen sind ein verbreiteter Entwicklerfehler.
• Logging-Probleme: Weitergabe von JWT in URLs oder Logs führt zu unbeabsichtigter Offenlegung.

Alternativen

Für Anwendungen mit Anforderungen an sofortige Revocation oder detaillierte Zugriffskontrolle bieten sich klassische Sessions mit serverseitiger Speicherung oder OAuth mit opaken Tokens an. OAuth 2.1 diskutiert Verbesserungen wie die Abschaffung des Implicit Grant und strengere Redirect-Requirements.

JWT ist kompromittiert, wenn Header oder URLs protokolliert werden. — Xygeni (Sicherheitsblog)

Verwandte Beiträge: Ping reduzieren: Tipps für Gaming, Roblox & Valorant · Windows 11 Kompatibilität Prüfen – Ist Ihr PC bereit?

JWT-Tokens eignen sich hervorragend für APIs, wobei der besonders im OAuth-Vergleich ihre stateless Natur klar hervortritt.

Häufig gestellte Fragen