Curious TechieDev Toolbox
Alle Leitfäden/Authentifizierung8 min read

Was ist ein JWT? JSON Web Token Architektur (RFC 7519)

Stateless-Authentifizierung, Header/Payload/Signatur-Aufbau, Base64URL, Algorithmus-Verwirrung und Verifikation.

Wichtigste Erkenntnisse
  • Ein JWT besteht aus drei durch Punkte getrennten Teilen: Header, Payload und Signatur.
  • Die Nutzdaten sind lediglich in Base64URL kodiert und können von jedem ohne Geheimnis eingesehen werden.
  • Ein JWT zu dekodieren bedeutet NICHT, es zu verifizieren: Gültigkeit erfordert die Signaturprüfung.
  • Die gefährliche alg: "none"-Schwachstelle entsteht, wenn Backends unsignierte Token akzeptieren.
  • Aufgrund des zustandslosen Charakters erfordert sofortiger Widerruf Sperrlisten oder kurze Laufzeiten.

In modernen zustandslosen Microservices und OAuth 2.0 / OpenID Connect-Infrastrukturen dienen JSON Web Tokens (JWT) als Standardmechanismus (RFC 7519) zur sicheren Übertragung von Identitätsnachweisen.

1. Die 3-teilige Token-Anatomie

Ein JWT besteht aus drei durch Punkte (.) getrennten Base64URL-kodierten Abschnitten:

1. Header (Rot)Algorithmus & Tokentyp
2. Payload (Lila)Claims & Benutzerdaten
3. Signatur (Blau)Kryptografischer Nachweis

2. Standard-Claims (iss, exp, sub, iat)

  • iss (Issuer): Ausstellende Instanz des Tokens.
  • sub (Subject): Eindeutige Benutzer- oder Mandanten-ID.
  • exp (Expiration Time): Unix-Zeitstempel für den Ablauf des Tokens.
  • iat (Issued At): Erstellungszeitpunkt des Tokens.

3. Symmetrische (HS256) vs Asymmetrische (RS256) Signierung

HS256 (HMAC-SHA256) verwendet einen gemeinsamen geheimen Schlüssel. RS256 (RSA-SHA256) nutzt einen privaten Schlüssel zum Signieren und einen öffentlichen Schlüssel (JWKS) zur Verifizierung durch Dritte ohne Weitergabe von Signierschlüsseln.

4. Kritische Sicherheitsfallen und Schwachstellen

Typische Schwachstellen sind das Akzeptieren von "alg": "none", das Speichern sensibler Tokens im localStorage (XSS-Gefahr) und die fehlende Signaturprüfung vor Verwendung der Payload-Daten.