JWT: Was ist ein JSON Web Token, Struktur und Verwendung

Was ist JWT?

JSON Web Token (JWT) ist ein offener Standard (RFC 7519), der eine kompakte und eigenständige Möglichkeit zur Übertragung von Informationen zwischen Parteien als JSON-Objekt definiert. Die Informationen im JWT werden als Claims bezeichnet — Aussagen über das Subjekt (Benutzer) und zusätzliche Attribute. Jeder Claim ist ein Schlüssel-Wert-Paar: Benutzerkennung, Rolle, Ablaufzeit, Aussteller.

JWT wird als eigenständig bezeichnet, weil alle für die Verifizierung erforderlichen Informationen im Token selbst enthalten sind. Der Server muss keine Datenbank oder externen Speicher aufrufen, um die Gültigkeit des Tokens zu überprüfen — er muss nur die Signatur prüfen. Diese Eigenschaft macht JWT ideal für verteilte Systeme und Microservice-Architekturen, bei denen mehrere Dienste Anfragen ohne gemeinsamen Sitzungsspeicher authentifizieren müssen.

Laut Auth0, 2025 verwenden mehr als 65 % der mobilen und Web-Anwendungen JWT als primäres Token-Format für die API-Authentifizierung und übertreffen damit undurchsichtige Token und Sitzungskennungen.

JWT-Struktur: Header, Payload und Signature

JWT besteht aus drei durch Punkte getrennten Teilen: header.payload.signature. Jeder Teil ist ein Base64url-codiertes JSON. Betrachten wir jeden Teil im Detail.

Header — Algorithmus und Token-Typ

Header enthält zwei Pflichtfelder: alg (Algorithmus — Signieralgorithmus) und typ (Typ — Token-Typ, immer „JWT“). Der Algorithmus kann symmetrisch (HS256 — HMAC mit SHA-256) oder asymmetrisch (RS256 — RSA mit SHA-256, ES256 — ECDSA mit P-256) sein. Asymmetrische Algorithmen sind vorzuziehen, da sie dem Client ermöglichen, die Signatur zu überprüfen, ohne den geheimen Schlüssel zu besitzen.

Beispiel eines decodierten Headers:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-id-1"
}

Payload — Claims und Daten

Payload enthält Claims — Aussagen über das Subjekt. Claims werden in drei Typen unterteilt: registrierte (iss, sub, aud, exp, nbf, iat, jti), öffentliche (vom Entwickler im IANA-Register definiert) und private (zwischen den Parteien vereinbarte). sub (Subject) ist die eindeutige Benutzerkennung. exp (Expiration) ist der Zeitstempel des Token-Ablaufs. iss (Issuer) ist der Aussteller des Tokens.

{
  "sub": "user-abc-123",
  "iss": "https://auth.example.com",
  "aud": "my-mobile-app",
  "exp": 1812345678,
  "iat": 1812342078,
  "role": "premium_user"
}

Signature — Integritätsprüfung

Signature wird erstellt, indem der Signieralgorithmus auf die Verkettung von Header und Payload mit einem geheimen oder privaten Schlüssel angewendet wird. Die Formel: HMACSHA256(base64UrlEncode(header) + „.“ + base64UrlEncode(payload), secret) für HMAC, oder RSASHA256(...) für asymmetrische Algorithmen. Der Empfänger berechnet die Signatur auf dieselbe Weise und vergleicht sie mit der empfangenen — wenn sie übereinstimmen, wurden die Daten nicht verändert.

Wie JWT funktioniert: Erstellung und Verifizierung

Der Arbeitsablauf mit JWT besteht aus zwei Phasen: der Erstellung (Ausstellung) des Tokens durch den Authentifizierungsserver und der Verifizierung des Tokens durch den Client oder Ressourcenserver. Der Authentifizierungsserver empfängt die Anmeldedaten des Benutzers, erstellt einen Payload mit Claims und signiert ihn. Das resultierende JWT wird dem Client als Antwort auf eine Login-Anfrage oder im Antworttext von OAuth 2.0 / OpenID Connect gesendet.

JWT in der mobilen Authentifizierung

In mobilen Anwendungen wird JWT wie folgt verwendet: Nach erfolgreichem Login erhält der Benutzer einen Zugriffstoken im JWT-Format. Die Anwendung speichert ihn in einem sicheren Speicher (Keychain auf iOS, EncryptedSharedPreferences auf Android). Bei jeder API-Anfrage fügt die Anwendung den Header Authorization: Bearer <token> hinzu. Der API-Server überprüft die JWT-Signatur, extrahiert die Claims und trifft darauf basierend Zugriffsentscheidungen — ohne Datenbankabfrage.

Laut Google Codelabs, 2025 reduziert die Verwendung von JWT in Firebase Authentication die Anzahl der Anfragen an den Authentifizierungsserver um 40–60 % im Vergleich zu Sitzungstokens, da die Daten lokal auf jedem Microservice überprüft werden. Dies ist besonders wichtig für Architekturen mit hoher Last, wo jede Millisekunde Latenz die Benutzererfahrung beeinflusst. Bei 50.000 Anfragen pro Minute kann der Wechsel zu JWT bis zu 10 Serverinstanzen einsparen, die Introspectionsanfragen verarbeiten.

JWT vs Session Token

JWT und Session Token lösen dasselbe Problem — Anfrageauthentifizierung — unterscheiden sich jedoch grundlegend in der Architektur. Session Token ist eine zufällige Kennungszeichenfolge, die auf serverseitig gespeicherte Sitzungsdaten verweist (zustandsbehaftet). JWT ist ein eigenständiger Token, der alle Daten in sich trägt (zustandslos).

Vorteile und Nachteile von JWT

JWT überzeugt in verteilten Systemen: Microservices können den Token lokal ohne gemeinsamen Speicher überprüfen. In einer Architektur mit fünf Microservices überprüft beispielsweise jeder Dienst JWT in 1–2 ms ohne Netzwerkaufruf, während ein Session Token bei jeder Anfrage eine zentrale Redis-Abfrage erfordert, die 10–30 ms Latenz hinzufügt. Allerdings ist JWT schwer zu widerrufen — einmal ausgestellt, ist es bis zum Ablauf gültig. Session Token lässt sich leicht widerrufen, indem der Eintrag aus der DB oder Redis gelöscht wird.

Für mobile Anwendungen bietet ein kombinierter Ansatz — JWT mit kurzer Lebensdauer (15–30 Minuten) und Refresh Token — ein Gleichgewicht zwischen Leistung und Sicherheit. JWT wird für den API-Zugriff verwendet, während der Refresh Token (normalerweise undurchsichtig) zum Erhalten neuer JWTs dient. Bei Kompromittierung eines JWT hat der Angreifer 15–30 Minuten Zugriff; bei Kompromittierung des Refresh Token wird die Sitzung durch Rotation und Wiederverwendungserkennung blockiert.

JWT-Sicherheit

Die Sicherheit von JWT hängt von der korrekten Implementierung ab. Die häufigste Schwachstelle ist der „alg none“-Angriff: Ein Angreifer ändert den Header des Tokens auf „alg“: „none“, und der Server akzeptiert den gefälschten Token, ohne den Algorithmus zu überprüfen. Schutz: Überprüfen Sie immer, ob der Algorithmus im Header dem erwarteten (RS256, ES256) entspricht, und lehnen Sie Tokens mit alg: none ab.

Häufige Schwachstellen

JWT-Schwachstellen umfassen auch: schwacher geheimer Schlüssel für HMAC (in Minuten erratbar), Leck des privaten Schlüssels (Signieren beliebiger Daten im Namen des Servers), Speicherung vertraulicher Daten im Payload (JWT verschlüsselt nicht, sondern signiert nur), JWK-Header-Injection-Angriff (Einschleusen eines eigenen öffentlichen Schlüssels). Die Verwendung vertrauenswürdiger Bibliotheken — Nimbus JOSE + JWT, jjwt (io.jsonwebtoken), PyJWT — verringert das Risiko der Ausnutzung dieser Schwachstellen.

Eine zusätzliche Sicherheitsmaßnahme ist JWK Thumbprint (RFC 7638): Bindung eines öffentlichen Schlüssels an den Token über einen Fingerabdruck (Thumbprint) im Header. Wenn der Server den erwarteten Fingerabdruck für jeden Client speichert, wird eine JWK-Header-Injection unmöglich — der Server lehnt jeden Schlüssel ab, der nicht mit dem registrierten übereinstimmt. Der OAuth Security Workshop 2025 empfiehlt JWK Thumbprint als obligatorischen Schutz für alle JWTs, die in Finanz- und Medizinanwendungen verwendet werden.

Codebeispiel: Arbeiten mit JWT in Kotlin

Die Bibliothek jjwt (auth0/java-jwt) ermöglicht das Erstellen und Überprüfen von JWTs in einer Android-Anwendung in nur wenigen Zeilen. Im folgenden Beispiel generiert der Server einen Token mit sub und role, und der Client überprüft die Signatur. Für die sichere Speicherung des geheimen Schlüssels auf dem Server verwenden Sie Umgebungsvariablen oder ein HSM (Hardware Security Module) — die Speicherung des Schlüssels im Code oder in einer Konfigurationsdatei ist ein schwerwiegender Sicherheitsfehler.

JWT-Generierung

val secret = "my-256-bit-secret-key-here"
val token = JWT.create()
    .withSubject("user-abc-123")
    .withIssuer("auth.example.com")
    .withClaim("role", "premium_user")
    .withExpiresAt(Date(System.currentTimeMillis() + 3600000))
    .sign(Algorithm.HMAC256(secret))

// Senden des Tokens an den Client
println("JWT: $token")

JWT-Verifizierung

fun verifyToken(token: String): Boolean {
    return try {
        val decoded = JWT.require(Algorithm.HMAC256(secret))
            .withIssuer("auth.example.com")
            .build()
            .verify(token)
        // Signatur gültig, Claims extrahiert
        println("Subject: ${decoded.subject}")
        true
    } catch (e: Exception) {
        println("Token ungültig: ${e.message}")
        false
    }
}