JWT (JSON Web Token)

JWT (JSON Web Token) ist ein offener Standard (RFC 7519) für die sichere Übertragung von Informationen zwischen zwei Parteien in Form eines kompakten, selbstenthaltenden Tokens.

Das Token basiert auf JSON und enthält alle notwendigen Informationen zur Authentifizierung und Autorisierung einer Entität. Dadurch entfallen zusätzliche Datenbankabfragen bei jeder Anfrage. JWTs werden hauptsächlich für API-Authentifizierung, Single Sign-On (SSO) und die Sicherung von Webdiensten eingesetzt.

Aufbau und Struktur eines JWT

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

Header.Payload.Signature

Ein konkretes Beispiel sieht so aus:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Ik1heCBNdXN0ZXJtYW5uIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header

Der Header (auch JOSE-Header genannt) enthält Metainformationen über das Token. Er definiert den verwendeten Signaturalgorithmus und den Token-Typ:

{
  "alg": "HS256",
  "typ": "JWT"
}

Das Feld alg gibt den Algorithmus an (z.B. HS256, RS256), mit dem die Signatur erstellt wurde. Das Feld typ identifiziert das Token als JWT.

Payload (Claims)

Die Payload enthält die eigentlichen Nutzdaten - die sogenannten Claims. Claims sind Aussagen über eine Entität, typischerweise den Benutzer. Es gibt drei Arten von Claims:

• Registered Claims: Standardisierte Felder wie iss (Aussteller), sub (Subjekt), exp (Ablaufzeit), iat (Ausstellungszeit)
• Public Claims: Öffentlich registrierte, standardisierte Namen
• Private Claims: Anwendungsspezifische Informationen wie Benutzerrollen oder Berechtigungen

Ein Beispiel für eine Payload:

{
  "sub": "1234567890",
  "name": "Max Mustermann",
  "role": "admin",
  "iat": 1516239022,
  "exp": 1516242622
}

Wichtig: Die Payload ist nur Base64-kodiert, nicht verschlüsselt. Jeder kann den Inhalt lesen - speichere daher niemals sensible Daten wie Passwörter im JWT.

Signatur

Die Signatur gewährleistet die Integrität und Authentizität des Tokens. Sie wird erstellt, indem Header und Payload mit einem geheimen Schlüssel gehasht werden:

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

Durch die Signatur kann der Empfänger verifizieren, dass das Token nicht manipuliert wurde. Bei asymmetrischer Verschlüsselung (RS256) wird mit einem privaten Schlüssel signiert und mit dem öffentlichen Schlüssel verifiziert.

Funktionsweise bei der Authentifizierung

Der Authentifizierungsprozess mit JWT folgt einem standardisierten Ablauf, der sich deutlich von traditionellen Session-basierten Verfahren unterscheidet:

1. Der Client sendet seine Anmeldedaten (z.B. Benutzername und Passwort) an den Server
2. Der Server überprüft die Credentials und erstellt bei Erfolg ein signiertes JWT
3. Der Client speichert das Token (typischerweise im Local Storage oder als Cookie)
4. Bei jeder weiteren Anfrage sendet der Client das JWT im HTTP-Header mit: Authorization: Bearer <token>
5. Der Server verifiziert die Signatur des Tokens und gewährt bei Gültigkeit Zugriff
6. Nach Ablauf der Gültigkeitsdauer muss sich der Benutzer erneut authentifizieren

Dieser Ablauf funktioniert auch über verschiedene Dienste hinweg: Ein Identity-Provider kann ein JWT ausstellen, das andere Service-Provider akzeptieren - die Basis für Single Sign-On.

JWT vs. Session-basierte Authentifizierung

JWT und klassische Sessions verfolgen unterschiedliche Ansätze bei der Authentifizierung. Die folgende Tabelle zeigt die wichtigsten Unterschiede:

Bei Stateless Sessions mit JWT müssen Sitzungen nicht auf dem Server gespeichert werden. Das macht die Architektur einfacher und besser skalierbar, bringt aber auch Nachteile mit sich - etwa bei der Invalidierung von Tokens.

Einsatzgebiete in der Praxis

JWT hat sich als De-facto-Standard für moderne Webanwendungen etabliert. Die wichtigsten Einsatzgebiete sind:

• RESTful APIs: JWTs sind ideal für die zustandslose Authentifizierung bei APIs
• Single Sign-On (SSO): Benutzer melden sich einmal an und können mehrere Anwendungen nutzen
• OAuth 2.0 und OpenID Connect: JWTs dienen als Access-Token und ID-Token
• Microservices: Dienste können Tokens ohne zentrale Session-Verwaltung akzeptieren
• Mobile Apps: Die zustandslose Natur passt perfekt zu mobilen Anwendungen
• Single Page Applications (SPAs): React, Vue und Angular nutzen JWT für clientseitige Authentifizierung

Sicherheitsaspekte und Best Practices

Die sichere Implementierung von JWT erfordert die Beachtung einiger wichtiger Regeln. Hier sind die wesentlichen Best Practices:

Gültigkeitsdauer begrenzen

Setze immer eine kurze Ablaufzeit (exp Claim). Access-Tokens sollten typischerweise nur 15-60 Minuten gültig sein. Für längere Sessions verwendest du zusätzlich Refresh-Tokens, die eine neue Authentifizierung ermöglichen.

Sichere Algorithmen verwenden

Verwende starke Signaturalgorithmen wie RS256 (asymmetrisch) oder HS256 (symmetrisch). Vermeide den none-Algorithmus und validiere den alg-Header serverseitig, um Algorithm-Confusion-Angriffe zu verhindern.

Sichere Speicherung

Speichere JWTs sicher auf dem Client. HTTP-Only Cookies bieten Schutz vor XSS-Angriffen, erfordern aber CSRF-Schutzmaßnahmen. Local Storage ist anfälliger für XSS, aber einfacher zu implementieren.

HTTPS verwenden

Übertrage JWTs ausschließlich über TLS-verschlüsselte Verbindungen. Unverschlüsselte Übertragung ermöglicht das Abfangen von Tokens durch Man-in-the-Middle-Angriffe.

Vor- und Nachteile von JWT

Wie jede Technologie hat auch JWT spezifische Stärken und Schwächen, die du bei der Entscheidung für oder gegen den Einsatz berücksichtigen solltest.

Vorteile

• Stateless: Keine serverseitige Session-Speicherung nötig
• Skalierbar: Ideal für verteilte Systeme und Load-Balancing
• Selbstenthalten: Alle Informationen im Token, keine Datenbankabfragen
• Plattformunabhängig: Funktioniert mit jeder Programmiersprache
• Standardisiert: RFC 7519 gewährleistet Interoperabilität

Nachteile

• Token-Größe: Größer als Session-IDs, mehr Bandbreite nötig
• Keine sofortige Invalidierung: Ausgestellte Tokens bleiben bis zum Ablauf gültig
• Komplexität: Sichere Implementierung erfordert Expertise
• Secret-Management: Die Verwaltung der Schlüssel ist kritisch
• Token-Diebstahl: Gestohlene Tokens können bis zum Ablauf missbraucht werden

Für die Invalidierung vor Ablauf benötigst du zusätzliche Mechanismen wie Token-Blacklists oder kurze Gültigkeitszeiten mit Refresh-Tokens.

JWT in der Praxis

JWT ist aus der modernen Webentwicklung nicht mehr wegzudenken. Besonders in der API-first-Entwicklung, bei Cloud-nativen Architekturen mit Microservices und bei Single Page Applications ist JWT der bevorzugte Authentifizierungsmechanismus.

Wer als Fachinformatiker für Anwendungsentwicklung im Web-Bereich arbeitet, wird JWT mit hoher Wahrscheinlichkeit begegnen - sei es bei der Implementierung von REST-APIs, der Integration von OAuth-Providern oder der Entwicklung von Single Page Applications.

Quellen und weiterführende Links

• RFC 7519 - JSON Web Token (JWT)
• JWT.io - Debugger und Dokumentation
• Auth0 - JSON Web Tokens Einführung
• OWASP - JWT Security Cheat Sheet