JWT
2 tools
Grundlagen der Web-Sicherheit
Web-Sicherheit ist die Praxis, Webanwendungen und APIs vor unbefugtem Zugriff, Datenverletzungen und Angriffen zu schützen. Moderne Anwendungen verwenden Authentifizierung, Autorisierung und Kryptographie.
JSON Web Tokens (JWT) sind der dominante zustandslose Authentifizierungsmechanismus in der modernen Webentwicklung.
JSON Web Tokens (JWT)
Ein JWT ist eine kompakte, URL-sichere Methode, Ansprüche zwischen zwei Parteien darzustellen. Er besteht aus drei Base64url-kodierten Teilen, getrennt durch Punkte.
Die drei Teile eines JWT
Enthält Metadaten über den Token: den Signaturalgorithmus (alg) und den Token-Typ (typ).
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9{
"alg": "HS256",
"typ": "JWT"
}Enthält die Claims: Aussagen über den Benutzer und zusätzliche Metadaten. Die Payload-Daten sind NICHT verschlüsselt, nur signiert.
eyJzdWIiOiJ1c2VyXzEyMyIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTcxNzIwMDAwMH0{
"sub": "user_123",
"role": "admin",
"exp": 1717200000
}Eine kryptographische Signatur über den kodierten Header und Payload. Die Überprüfung dieser Signatur stellt sicher, dass der Token nicht manipuliert wurde.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cHMACSHA256( base64url(header) + "." + base64url(payload), secret )
Standard-JWT-Claims
Die JWT-Spezifikation definiert Standard-Claim-Namen für die Interoperabilität:
| Claim | Name | Beschreibung |
|---|---|---|
| iss | Issuer | Identifiziert den Principal, der den Token ausgestellt hat |
| sub | Subject | Identifiziert den Principal, der das Subjekt des Tokens ist (z.B. Benutzer-ID) |
| aud | Audience | Identifiziert die Empfänger, für die der Token bestimmt ist |
| exp | Expiration | Unix-Timestamp, nach dem der Token nicht mehr akzeptiert werden darf |
| nbf | Not Before | Unix-Timestamp, vor dem der Token nicht akzeptiert werden darf |
| iat | Issued At | Unix-Timestamp, zu dem der Token ausgestellt wurde |
| jti | JWT ID | Eindeutiger Bezeichner für den Token, verhindert Token-Replay-Angriffe |
Signaturalgorithmen
Der Signaturalgorithmus wird im JWT-Header deklariert. Die richtige Wahl ist für die Sicherheit entscheidend:
HS256 / HS384 / HS512Symmetrisch (HMAC)Verwendet einen gemeinsamen geheimen Schlüssel zum Signieren und Verifizieren.
RS256 / RS384 / RS512Asymmetrisch (RSA)Verwendet einen privaten Schlüssel zum Signieren und einen öffentlichen Schlüssel zum Verifizieren.
ES256 / ES384 / ES512Asymmetrisch (ECDSA)Wie RSA, aber mit kleineren Schlüsseln und schnellerer Signierung.
"alg": "none"Unsigniert — GEFÄHRLICHKeine Signatur. Ein Token mit alg:none hat keine Integritätsgarantie und kann von jedem gefälscht werden.
Authentifizierungsabläufe
- 1.Benutzer sendet Benutzername und Passwort an den Login-Endpunkt
- 2.Server validiert Anmeldedaten gegen die Benutzerdatenbank
- 3.Server signiert einen JWT mit Benutzer-Claims und Ablaufzeit
- 4.Client speichert JWT (localStorage, Cookie oder Speicher)
- 5.Client sendet JWT im Authorization: Bearer-Header für nachfolgende Anfragen
- 1.Client leitet Benutzer zum Autorisierungsserver mit Code-Challenge weiter
- 2.Benutzer authentifiziert sich und autorisiert die Client-Anwendung
- 3.Auth-Server leitet zurück mit einem einmaligen Autorisierungscode
- 4.Client tauscht Code + Verifier gegen Zugriffs- und Refresh-Token aus
- 5.Client verwendet Zugriffstoken für API-Aufrufe; Refresh-Token zur Erneuerung
Häufige JWT-Schwachstellen
JWTs sind sicher, wenn sie korrekt implementiert werden. Dies sind die häufigsten Implementierungsfehler:
Einige Bibliotheken akzeptieren Tokens mit alg:none. Ein Angreifer kann die Payload ändern und alg auf none setzen, um beliebige JWTs zu fälschen.
Wenn eine Bibliothek RS256 verifizieren soll, aber HS256 akzeptiert, kann ein Angreifer einen Token mit dem öffentlichen Schlüssel als HMAC-Geheimnis signieren.
Ein JWT ohne exp-Claim oder Code, der exp nicht prüft, ermöglicht die unbegrenzte Verwendung von Tokens.
JWT-Payloads sind Base64-kodiert, nicht verschlüsselt. Niemals Passwörter oder andere Geheimnisse in JWT-Claims speichern.
HMAC-signierte JWTs mit kurzen oder vorhersehbaren Geheimnissen können offline per Brute-Force geknackt werden.
JWTs ohne Signaturprüfung zu akzeptieren vertraut der Payload vollständig. Die Signatur immer vor dem Vertrauen in Claims verifizieren.
Häufig gestellte Fragen
Standard-JWTs (JWS) sind signiert, aber NICHT verschlüsselt. Die Payload ist Base64url-kodiert, was trivial umkehrbar ist.
Zugriffstoken sollten kurzlebig sein: 5–60 Minuten ist typisch. Refresh-Token für den Erhalt neuer Zugriffstoken verwenden.
HttpOnly-Cookies sind die sicherste Option — sie sind für JavaScript nicht zugänglich und verhindern XSS-Diebstahl.
Nicht ohne serverseitigen Zustand. Lösungen: kurze Ablaufzeiten, eine Token-Sperrliste (Redis).
Session-Cookies speichern eine zufällige Session-ID; der Server sucht die Session-Daten. JWTs sind eigenständig — der Server validiert die Signatur ohne Datenbankabfrage.
Das Minimum: sub (Benutzer-ID), exp (Ablauf) und iat (ausgestellt am). Payloads klein halten.
RS256 (asymmetrisch) ist für die meisten Produktionssysteme besser, da nur der Auth-Server den privaten Schlüssel benötigt.
PKCE ist eine Erweiterung des OAuth2-Autorisierungscode-Flows, die Autorisierungscode-Abfangangriffe verhindert. Es ist für öffentliche Clients (SPAs, mobile Apps) erforderlich.