Wer bei modernen APIs oder Single-Sign-On-Lösungen unterwegs ist, stößt früher oder später auf JWT – und oft genug auf die verwirrende Frage, ob das dasselbe wie OAuth ist oder wofür man es überhaupt braucht. Kein Wunder: Das Kürzel tauft man schnell zum „JWT-Token”, obwohl das T für Token schon im Namen steckt. Dieser Beitrag räumt auf mit den Missverständnissen, erklärt die dreiteilige Struktur und zeigt, wie sich JWT und OAuth unterscheiden – mit praktischen Schritten zur Generierung und einem ehrlichen Blick auf Vor- und Nachteile.

Diese Beitrage nicht verpassen

4 verwandte Artikel

Standard: RFC 7519 · Format: Kompakt, selbstenthaltend · Zweck: Sichere Übertragung von Claims · Header-Payload-Signature: Drei Teile Base64-kodiert · Offen: IETF-Standard

Kurzüberblick

1Bestätigte Fakten
2Was unklar ist
  • Welche Algorithmen in der Praxis am häufigsten verwendet werden (HS256 vs. RS256)
  • Optimale Ablaufzeiten für verschiedene Anwendungsfälle ohne branchenspezifische Standards
  • Detaillierte Statistiken zur Verbreitung von JWT vs. Sessions in Unternehmenssystemen
3Zeitleisten-Signal
  • JWT RFC 7519 veröffentlicht im Mai 2015 (OOSE Blog)
  • Weitverbreitete Adoption in APIs zwischen 2016 und 2020 (Leapcell Blog)
  • Keycloak etabliert als OAuth-Implementierung seit 2014 (codecentric)
4Wie es weitergeht
  • Wachsende Kombination von OAuth 2.0 mit JWT für Microservices-Authentifizierung
  • Zunehmender Fokus auf kurze Ablaufzeiten und sichere Schlüsselverwaltung als Best Practice
  • OpenID Connect bleibt relevante Erweiterung für Identity-Layer über JWT hinaus
Merkmal Details
Definition Open Standard für sichere Claims-Übertragung
RFC 7519
Teile Header.Payload.Signature
Sicherheit Signatur optional verschlüsselt
Payload Claims iss, sub, aud, exp
Typische Algorithmen HS256, RS256

Was macht ein JWT-Token?

Ein JWT (JSON Web Token) ist ein kompaktes, selbstenthaltendes Format, das Informationen als JSON-Objekt austauscht und dabei durch eine kryptografische Signatur vor Manipulation schützt. Der Standard wurde 2015 als RFC 7519 von der IETF veröffentlicht.

Übertragung sicherer Informationen

JWT ermöglicht die sichere Übertragung von Claims – also Aussagen über einen Benutzer oder ein System – zwischen zwei Parteien. Das Besondere: Der Resource Server kann das Token lokal validieren, ohne bei jedem Request eine Anfrage an den Authorization Server zu senden. Das macht JWT besonders geeignet für zustandslose Architekturen und skalierbare Systeme.

Selbstenthaltende Claims

Die Payload eines JWT enthält verschiedene Claims: Registered Claims wie iss (issuer/Aussteller), sub (subject/Betreffen), aud (audience/Zielgruppe) und exp (expiration/Ablaufzeit) gehören zum Standard. Daneben gibt es Public und Private Claims für anwendungsspezifische Daten.

Fazit: JWT fungiert als digitaler Ausweis, der Berechtigungen und Identitätsinformationen direkt enthält – ohne dass der Server bei jeder Anfrage die Datenbank bemühen muss.

Was ist der Unterschied zwischen JWT und OAuth?

Die häufigste Verwechslung: JWT wird oft mit OAuth gleichgesetzt, dabei erfüllen beide grundlegend verschiedene Aufgaben. Der Logto Blog beschreibt den Unterschied treffend: „OAuth ist die Art, wie du jemandem die Schlüssel gibst, aber nur für die Räume, in die er eintreten darf. JWT ist die Ausweiskarte, die er bei sich trägt.”

JWT als Token-Format

JWT ist ein Datenformat – konkret: eine Repräsentation von Informationen in Base64url-kodierter Form. Es sagt nichts darüber aus, wie ein Token ausgestellt oder widerrufen wird. JWT kann allein für die Authentifizierung in einem einzelnen System verwendet werden.

OAuth als Autorisierungs-Framework

OAuth 2.0 hingegen ist ein Protokoll-Framework mit definierten Abläufen (Flows) für die Zugriffsdelegation. Es spezifiziert nicht selbst, wie ein Token strukturiert sein muss – hier kommt oft JWT ins Spiel. Laut dem OOSE Blog ergänzt JWT das OAuth-Framework, indem es eine konkrete Token-Struktur bereitstellt.

Warum das zusammenpasst

In OAuth-Flows dient JWT häufig als Access Token oder ID Token. Der ID-Token in OpenID Connect ist per Spezifikation immer ein JWT. OAuth bringt die Logik mit (wer darf was anfordern), JWT das Format für die sichere Übertragung.

Die vier OAuth-Akteure – Resource Owner (Benutzer), Client (App), Authorization Server und Resource Server – arbeiten in definierten Flows zusammen, während JWT als konkretes Token-Format fungiert, das diese Flows mit Daten versorgt.

Fazit: OAuth 2.0 definiert das „Wer darf zugreifen und unter welchen Bedingungen”, JWT das „Was steht im Ausweis und wie ist es gesichert”. Beides ergänzt sich, ist aber nicht dasselbe.

Wie generiert man ein JWT-Token?

Die Generierung eines JWT folgt einem klaren Muster: Nach erfolgreicher Benutzeranmeldung signiert der Server die Token-Daten mit einem geheimen Schlüssel und übergibt das Ergebnis an den Client.

Schritte zur Erstellung

  1. Header erstellen: Der Header enthält den Algorithmus (z.B. HS256 für symmetrische Signierung) und den Typ „JWT”.
  2. Payload zusammenstellen: Hier werden die Claims eingetragen – Standard-Claims wie sub, iat (issued at) und optionale Claims für Berechtigungen oder Rollen.
  3. Signatur berechnen: Header und Payload werden Base64url-kodiert, dann mit dem geheimen Schlüssel (secretKey) signiert.
  4. Token zusammenfügen: Die drei Teile werden mit Punkten verbunden: header.payload.signature.

Ein typisches Ablaufdatum wird mit expiresIn: '24h' gesetzt, wie der Leapcell Blog zeigt.

Benötigte Schlüssel

Für symmetrische Algorithmen wie HS256 genügt ein gemeinsamer Secret Key zwischen Server und API. Für asymmetrische Algorithmen wie RS256 nutzt der Aussteller einen privaten Schlüssel, während der Resource Server mit dem öffentlichen Schlüssel validiert.

Best Practice

Der Schlüsselschutz entscheidet über die Sicherheit des gesamten Systems. Private Schlüssel sollten in speziellen Vault-Systemen gespeichert werden, niemals im Quellcode oder in Konfigurationsdateien.

JWT-Bibliotheken wie jwt.io vereinfachen die Generierung erheblich und unterstützen verschiedene Programmiersprachen.

Fazit: Ein JWT entsteht durch Signierung von Header und Payload – der Server braucht dafür einen geschützten Schlüssel, die Validierung auf Empfängerseite erfolgt mit dem passenden öffentlichen Schlüssel.

Was ist die Struktur eines JWT-Tokens?

Ein JWT besteht aus genau drei Teilen, die mit Punkten getrennt und jeweils Base64url-kodiert sind: Header.Payload.Signature. Pexon Consulting beschreibt diese Struktur als Grundlage für die kryptografische Absicherung.

Header

Der Header ist ein JSON-Objekt, das mindestens zwei Felder enthält: alg (der Signaturalgorithmus, z.B. HS256 oder RS256) und typ (der Token-Typ, immer „JWT”).

Payload

Die Payload enthält die eigentlichen Daten – die Claims. Registered Claims wie sub (Benutzer-ID), iss (Aussteller), aud (Zielgruppe) und exp (Ablaufzeit) sind standardisiert. Daneben existieren Public Claims (öffentlich dokumentiert) und Private Claims (anwendungsspezifisch).

Signature

Die Signatur wird erzeugt, indem der Base64url-kodierte Header und Payload mit dem geheimen oder privaten Schlüssel signiert werden. Der Empfänger kann damit prüfen, ob das Token während der Übertragung verändert wurde.

„JWT ist ein in sich geschlossenes, kompaktes Format, um Informationen als JSON-Objekt auszutauschen.”

— OOSE Blog

Ein dekodiertes JWT-Beispiel sieht so aus:

  • Header: {"alg":"HS256","typ":"JWT"}
  • Payload: {"sub":"1234567890","iss":"beispiel.de","exp":1719254400}
  • Signature: HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), geheimer_schluessel)
Fazit: Header definieren, wie das Token gesichert ist; Payload enthält die Daten; Signature garantiert die Unversehrtheit. Zusammen ergeben sie das kompakte JWT-Format.

Vor- und Nachteile von JWT?

JWT bietet klare Vorteile für moderne Authentifizierungssysteme, bringt aber auch Risiken mit sich, die Entwickler kennen sollten. Der Leapcell Blog stellt beide Seiten ehrlich gegenüber.

Vorteile

  • Zustandslos und skalierbar: Der Resource Server validiert JWTs lokal mit dem Public Key – keine Server-Anfragen für jede Validierung nötig.
  • Leichtgewichtig: Durch Base64url-Kodierung kompakt und effizient für die Übertragung.
  • Enthält Berechtigungen: Rollen und Rechte sind direkt im Token kodiert.
  • Cross-Domain-Unterstützung: JWTs funktionieren plattformübergreifend, ideal für Microservices.
  • Offener Standard: RFC 7519 ist öffentlich dokumentiert und gut geprüft.

Nachteile und Kritik

  • Missbrauch bei Kompromittierung: Ist ein Token gestohlen, kann es bis zum Ablauf missbraucht werden – ein Widerruf ist nicht ohne Weiteres möglich.
  • Schlüsselabhängigkeit: Die gesamte Sicherheit hängt vom Schutz des geheimen Schlüssels ab.
  • Keine native Sperrung: Einmal ausgestellte Token können nicht zentral gesperrt werden (ohne zusätzliche Mechanismen wie Blocklisten).
  • Fehlkonfigurationsrisiken: Unerfahrene Entwickler können unsichere Algorithmen wählen oder Schlüssel öffentlich machen.
Der Haken

Die Sicherheit von JWT hängt maßgeblich von kurzen Ablaufzeiten und dem sicheren Schlüsselmanagement ab. Ein langlebiges Token mit exponiertem Schlüssel ist ein erhebliches Risiko.

Für den Logto Blog sind Best Practices entscheidend: HTTPS verwenden, den aud-Claim prüfen und kurze Gültigkeiten setzen – im Idealfall nur wenige Minuten.

Vorteile

  • Zustandslos, skalierbar, cross-domain-fähig
  • Enthält Berechtigungen direkt im Token
  • Offener, gut geprüfter Standard

Nachteile

  • Keine native Sperrung möglich
  • Abhängig von Schlüsselschutz
  • Risiko bei Diebstahl bis Ablauf
Fazit: JWT eignet sich hervorragend für zustandslose, skalierbare Systeme – aber nur mit kurzen Ablaufzeiten, sicherem Schlüsselmanagement und dem Verständnis, dass das Token nicht ohne Weiteres gesperrt werden kann.

JWT vs. OAuth: Der Vergleich

Um die Unterschiede zwischen JWT und OAuth greifbar zu machen, hilft ein direkter Vergleich der wesentlichen Merkmale.

Drei zentrale Aspekte unterscheiden JWT und OAuth grundlegend: JWT definiert ein Datenformat, OAuth einen Protokollrahmen. JWT kann allein verwendet werden, OAuth nicht ohne Token-Format. OAuth ermöglicht granulare Zugriffsrechte mit unterschiedlichen Lebenszeiten, während JWT diese direkt kodiert.

Kriterium JWT OAuth 2.0
Rolle Token-Format (Datenrepräsentation) Framework (Prozess/Flows)
Allein nutzbar Ja, für Single-System-Authentifizierung Nein, benötigt Token-Format
Spezifikation RFC 7519 (Mai 2015) RFC 6749 (Oktober 2012)
Token-Struktur Definiert (Header.Payload.Signature) Nicht spezifiziert
Zugriffskontrolle Enthält Berechtigungen im Token Delegiert Zugriff mit Flows

Die Wahl hängt vom Anwendungsfall ab: Wer ein einzelnes System absichert, kommt oft mit JWT allein aus. Wer dagegen granulare Zugriffskontrolle über mehrere Dienste hinweg braucht, profitiert von OAuth – oft in Kombination mit JWT als Token-Format.

„Die Sicherheit von JWT hängt vom Schlüsselschutz und der Token-Ablaufverwaltung ab.”

— Leapcell Blog

Die Empfehlung

Für Microservices-Architekturen hat sich die Kombination bewährt: OAuth 2.0 für die Flows und JWT als konkretes Token-Format. Das bietet Flexibilität bei gleichzeitig standardisierter Datenrepräsentation.

Verwandte Beiträge: Visual C++ Compiler Tools · Online-Foto-Speicher Optionen

Weitere Quellen

kedso-learning.de

Häufig gestellte Fragen

Warum sagen Leute „JWT-Token”?

Weil das Akronym JWT für „JSON Web Token” steht und „Token” bereits enthält. „JWT-Token” ist also eine Redundanz – vergleichbar mit „PIN-Nummer”. In der Praxis hat sich die Bezeichnung dennoch eingebürgert.

Kann JWT ohne OAuth verwendet werden?

Ja. JWT kann eigenständig für die Authentifizierung in einem einzelnen System verwendet werden. Der Vorteil: Die API validiert das Token ohne Server-Anfrage. Für komplexere Szenarien mit Zugriffsdelegation über mehrere Dienste empfiehlt sich die Kombination mit OAuth 2.0.

Was ist besser, JWT oder OAuth?

Beides erfüllt verschiedene Aufgaben und ist daher nicht direkt vergleichbar. JWT ist ein Token-Format, OAuth ein Autorisierungs-Framework. Für einfache API-Authentifizierung reicht JWT. Für granulare Zugriffskontrolle über Dienste hinweg ist OAuth mit JWT als Token-Format die bessere Wahl.

Wie dekodiert man ein JWT?

Ein JWT besteht aus drei Base64url-kodierten Teilen. Die Teile können mit Base64url-Dekodern getrennt werden. Der Header und die Payload werden direkt als JSON lesbar. Die Signatur erfordert den passenden Schlüssel zur Validierung. Online-Tools wie jwt.io machen das Dekodieren interaktiv möglich.

Was ist ein JWT-Secret?

Das JWT-Secret ist der geheime Schlüssel, mit dem die Signatur eines JWT berechnet wird. Bei symmetrischen Algorithmen wie HS256 teilen Aussteller und Validator den gleichen Schlüssel. Bei asymmetrischen Algorithmen wie RS256 nutzt der Aussteller einen privaten Schlüssel, der Empfänger einen öffentlichen.

Wie lange läuft ein JWT-Token?

Die Gültigkeitsdauer wird im exp-Claim festgelegt und ist frei wählbar. Typische Werte sind wenige Minuten bis 24 Stunden. Kurze Ablaufzeiten erhöhen die Sicherheit, da gestohlene Token schneller wertlos werden. Refresh Tokens ermöglichen die Verlängerung ohne erneute Anmeldung.

Wie funktioniert JWT-Authentifizierung?

Nach der Anmeldung erhält der Client ein signiertes JWT. Bei jedem Request sendet der Client das Token im Authorization-Header. Der Resource Server validiert die Signatur mit dem Public Key und prüft die Claims (z.B. Ablaufzeit, Zielgruppe). Ist alles korrekt, wird die Anfrage autorisiert – ohne Datenbankzugriff für die Validierung.

Für Entwickler, die moderne APIs absichern wollen, ist die Entscheidung klar: JWT allein reicht für einfache Fälle, die Kombination mit OAuth 2.0 für komplexere Anforderungen. Der Schlüssel liegt im sicheren Schlüsselmanagement und kurzen Ablaufzeiten – dann liefert JWT genau das, was es verspricht: ein kompaktes, prüfbares Identitätstoken.