← Zurück zum Glossar
webentwicklung

JWT

JSON Web Token — kompaktes, selbst-beschreibendes Token-Format für die Authentifizierung und den Datenaustausch zwischen Parteien.

Aktualisiert: 23. Februar 2026

Was ist JWT?

JWT (JSON Web Token, ausgesprochen "jot") ist ein offener Standard (RFC 7519 ) für kompakte, URL-sichere Token, die Informationen zwischen Parteien als JSON-Objekt übertragen. Das Besondere: Ein JWT ist selbst-beschreibend — es enthält alle notwendigen Informationen zur Verifikation in sich selbst, ohne dass der Server eine Session-Datenbank abfragen muss. Ein gültiges JWT beweist, dass es von einem bestimmten Aussteller signiert wurde und die enthaltenen Claims unverändert sind.

JWTs werden häufig für Authentifizierung (nach dem Login wird ein JWT ausgestellt, das der Client bei jedem Request mitschickt) und für sichere Datenübertragung (z.B. OAuth 2.0-Flows, API-Authentifizierung) verwendet. Ihre Popularität kommt von der Statelessness: Der Server muss keine Sessions verwalten.

Kurzprofil JWT

Kurzprofil

  • Typ: Token-Format / Standard
  • Spezifikation: RFC 7519 (2015)
  • Verwandte Standards: JWS (Signierung), JWE (Verschlüsselung), JWKS (Key Sets)
  • Typische Algorithmen: HS256, RS256, ES256
  • Relevanz für WordPress/Web: Hoch bei REST-API-Authentifizierung

Wie funktioniert JWT?

Ein JWT besteht aus drei Base64URL-codierten Teilen, getrennt durch Punkte:

header.payload.signature

Header — Metadaten über das Token:

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

Payload — die eigentlichen Claims (Aussagen):

{
  "sub": "user_42",
  "iss": "https://auth.example.com",
  "aud": "https://api.example.com",
  "exp": 1740000000,
  "iat": 1739996400,
  "roles": ["editor"]
}

Signature — kryptografische Signatur:

RS256(base64url(header) + "." + base64url(payload), privateKey)

Der Empfänger verifiziert die Signatur mit dem öffentlichen Schlüssel des Ausstellers. Ist die Signatur gültig, sind die Claims vertrauenswürdig. Ist exp (Expiration) überschritten, ist das Token abgelaufen.

Wichtig: JWT-Payload ist nicht verschlüsselt — nur signiert. Jeder kann Base64-decodieren und den Inhalt lesen. Keine sensiblen Daten (Passwörter, Bankdaten) in den Payload!

JWT in der Praxis

Für WordPress-REST-API-Authentifizierung wird JWT über Plugins wie JWT Authentication for WP-API implementiert:

# Token abrufen:
curl -X POST https://example.com/wp-json/jwt-auth/v1/token \
  -d '{"username": "admin", "password": "..."}'
# Response: {"token": "eyJhbGciOi...", "user_email": "..."}

# Token verwenden:
curl https://example.com/wp-json/wp/v2/posts \
  -H "Authorization: Bearer eyJhbGciOi..."

Typische Algorithmus-Auswahl:

  • HS256 (HMAC-SHA256): Symmetrisch — Aussteller und Empfänger teilen denselben geheimen Schlüssel. Einfach, aber: Jeder der das Token verifizieren kann, kann auch welche ausstellen.
  • RS256 (RSA-SHA256): Asymmetrisch — privater Schlüssel zum Signieren, öffentlicher zum Verifizieren. Empfohlen wenn Token von Drittparteien verifiziert werden.
  • ES256 (ECDSA): Asymmetrisch, kürzere Schlüssel als RSA bei gleicher Sicherheit.
Auf einen Blick

Das Wichtigste

  • JWT = Header.Payload.Signature — alles in einem Token, kein Server-State nötig
  • Payload ist Base64-codiert, nicht verschlüsselt — keine Passwörter oder sensible Daten im Payload
  • exp-Claim (Expiration) prüfen — abgelaufene Tokens müssen abgelehnt werden
  • RS256 (asymmetrisch) bevorzugen wenn Dritte Token verifizieren sollen
  • JWTs können nicht widerrufen werden (ohne Token-Blacklist) — kurze Ablaufzeiten verwenden

Was passiert wenn JWT falsch implementiert ist?

Die Geschichte der JWT-Sicherheitslücken ist lang. Die klassische Lücke: Manche frühen Bibliotheken akzeptierten "alg": "none" (kein Algorithmus, keine Signatur) wenn der Payload entsprechend gesetzt war — was bedeutete, dass jeder beliebige Claims ohne Signatur einschleusen konnte. Seriöse Bibliotheken lehnen alg: none heute ab, aber der Grundsatz bleibt: Immer explizit erlaubte Algorithmen whitelist-artig konfigurieren.

Weitere typische Fehler: Keine Expiration-Zeit (exp-Claim) → Token läuft nie ab und kann bei Kompromittierung nie ungültig gemacht werden. Zu lange Ablaufzeiten → kompromittierte Tokens bleiben lange nutzbar. Fehlende Audience-Validierung (aud) → Token für Service A funktioniert auch bei Service B.

Häufige Fragen

Was ist der Unterschied zwischen JWT und Session-Cookies? Session-Cookies speichern eine Session-ID; der Server muss die Session-ID in einer Datenbank nachschlagen. JWTs sind self-contained — der Server braucht keine Datenbank. JWTs skalieren besser horizontal, aber Sessions können einfach widerrufen werden (Session aus Datenbank löschen). JWTs können nur durch Ablauf oder Token-Blacklisting ungültig gemacht werden.

Kann ich JWTs in WordPress-Nonces ersetzen? Nein — WordPress-Nonces sind für andere Zwecke konzipiert (CSRF-Schutz, kurzzeitige Aktions-Tokens). JWTs eignen sich für API-Authentifizierung über Service-Grenzen hinweg. Innerhalb einer WordPress-Installation sind Nonces meist die bessere Wahl.

Wo sollte ich JWTs im Browser speichern? In httpOnly-Cookies (nicht per JavaScript zugänglich, schützt vor XSS-Diebstahl) oder im Memory (flüchtig, verloren beim Tab-Schließen). localStorage und sessionStorage sind anfällig für XSS-Angriffe und werden von Sicherheitsexperten für Access Tokens nicht empfohlen.

Verwandte Begriffe

HTTPS · REST API

start call_