JWT (JSON Web Token)
Ein JSON Web Token (JWT) ist ein kompakter, URL-sicherer Token-Standard (RFC 7519) für die sichere Übertragung von Informationen zwischen zwei Parteien. JWTs werden in modernen Webapps als Authentifizierungsmechanismus eingesetzt: Nach dem Login erhält der Client einen signierten Token, der bei jeder API -Anfrage mitgesendet wird und die Identität des Benutzers nachweist.
Aufbau eines JWT: Header, Payload, Signature
Ein JWT besteht aus drei Base64-kodierten Teilen, getrennt durch Punkte: Header (Algorithmus und Token-Typ), Payload (Claims: Benutzer-ID, Rollen, Ablaufzeit) und Signature (kryptografische Signatur mit einem geheimen Schlüssel). Der Server validiert die Signatur bei jeder Anfrage – eine Manipulation des Payloads macht die Signatur ungültig. JWTs sind signiert, aber nicht verschlüsselt – der Payload ist lesbar.
Warum JWT statt Session-Cookies?
Klassische Session-Authentifizierung speichert den Zustand auf dem Server (Session-Store). JWTs sind zustandslos: Der Token enthält alle nötigen Informationen, der Server muss keinen Zustand vorhalten. Das vereinfacht Skalierung und Microservices -Architekturen. Allerdings: Token-Invalidierung (z. B. bei Logout) erfordert eine Blacklist, was den Zustandslosigkeitsvorteil teilweise aufhebt.
JWT-Sicherheit: Best Practices
Kurze Ablaufzeiten (15-30 Minuten) für Access-Tokens. Refresh-Tokens mit längerer Laufzeit für Token-Erneuerung. HttpOnly-Cookies statt localStorage (verhindert XSS-Zugriff). Signing-Key als dediziertes Secret im Secret Management verwalten. Token-Rotation: Bei jedem Refresh wird ein neues Token-Paar ausgestellt, das alte invalidiert. CSRF-Schutz bei Cookie-basierter Token-Übertragung. Zwei-Faktor-Authentifizierung als zusätzliche Schutzschicht.
JWT und OAuth 2.0
JWTs werden häufig als Token-Format in OAuth 2.0 -Flows eingesetzt. OAuth 2.0 definiert den Autorisierungsfluss (wie ein Token angefordert wird), JWT definiert das Token-Format (wie die Daten strukturiert sind). OpenID Connect (OIDC) baut auf OAuth 2.0 auf und standardisiert den Einsatz von JWTs für Identitäts-Tokens. Die Kombination ermöglicht sichere Single-Sign-On-Lösungen.
Wie wir es einsetzen
In unseren Django-REST-Backends transportieren wir JWTs ausschließlich in HttpOnly-Cookies – nie in localStorage, um XSS-Angriffe zu eliminieren. Access-Tokens laufen nach 15 Minuten ab, Refresh-Tokens werden bei jeder Verwendung rotiert und per Redis-Blacklist invalidiert. Der JWT-Signing-Key wird als eigenes Secret verwaltet, getrennt vom Django SECRET_KEY, und über Secret Management in der CI/CD -Pipeline injiziert. CSRF-Schutz ist zusätzlich aktiv.