JWTs: Was steckt wirklich in diesen langen Strings?
JSON Web Tokens dekodiert. Wie sie funktionieren, was sie enthalten und häufige Sicherheitsfehler.
Du siehst einen String wie eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U in deinem Auth-System.
Was ist das? Es ist ein JWT – drei Base64-kodierte Chunks, getrennt durch Punkte. Und du kannst es ohne spezielle Schlüssel lesen.
Die drei Teile
Header: Algorithmus und Token-Typ
{"alg": "HS256", "typ": "JWT"}
Payload: Die tatsächlichen Daten (Claims)
{"sub": "1234567890", "name": "John", "iat": 1516239022}
Signatur: Verifikation, dass nichts manipuliert wurde
JWTs sind nicht verschlüsselt
Das ist der große Punkt. Jeder kann ein JWT dekodieren und seinen Inhalt lesen. Base64 ist Kodierung, nicht Verschlüsselung.
Lege keine Geheimnisse in JWTs. Nutzer-IDs, Berechtigungen, Ablaufzeiten – ok. Passwörter, Kreditkarten, private Daten – niemals.
Standard-Claims
iss — Issuer. Wer hat dieses Token erstellt.
sub — Subject. Normalerweise die Nutzer-ID.
exp — Expiration. Unix-Timestamp, wann das Token ungültig wird.
iat — Issued at. Wann das Token erstellt wurde.
aud — Audience. Wer sollte dieses Token akzeptieren.
Custom Claims funktionieren auch. Füge hinzu, welche Daten deine Anwendung braucht.
Wie Signaturen funktionieren
Die Signatur beweist, dass das Token nicht modifiziert wurde.
Server erstellt Token → signiert mit geheimem Schlüssel → sendet an Client. Client sendet Token zurück → Server verifiziert Signatur → vertraut dem Inhalt.
Wenn jemand den Payload ändert, passt die Signatur nicht. Der Server lehnt ab.
Aber der Server muss die Signatur verifizieren. JWTs ohne Verifikation sind Sicherheitstheater.
Häufige Sicherheitsfehler
Signaturen nicht verifizieren. Einiger Code dekodiert JWTs ohne Signatur zu prüfen. Jeder kann Tokens fälschen.
Schwache Secrets verwenden. secret123 ist kein Secret. Verwende lange, zufällige Strings.
Ablauf ignorieren. Prüfe immer exp. Tokens sollten kurze Lebenszeiten haben.
Algorithmus-Verwirrung. Das alg-Feld sagt, wie verifiziert werden soll. Angreifer können es auf none setzen und Verifikation überspringen, wenn dein Code dem Header vertraut.
Sensible Daten speichern. Jeder mit dem Token kann den Payload lesen. Halte Secrets serverseitig.
Wann JWTs verwenden
Statuslose Authentifizierung. Server muss keine Sessions speichern. Das Token enthält alles Benötigte.
Microservices. Services können Tokens verifizieren ohne den Auth-Server aufzurufen.
Single Sign-On. Authentifizierung über Domains hinweg teilen.
Wann JWTs nicht verwenden
Einfache Apps. Session-Cookies sind simpler und schwerer zu vermasseln.
Sofortiges Widerrufen nötig. JWTs sind bis zum Ablauf gültig. Widerrufen erfordert zusätzliche Infrastruktur.
Große Payloads. Jede Anfrage trägt das volle Token. Große Tokens bedeuten mehr Bandbreite.
Refresh Tokens
Access Tokens sollten kurzlebig sein (Minuten bis Stunden). Refresh Tokens holen neue Access Tokens ohne erneute Authentifizierung.
Speichere Refresh Tokens sicher. Sie sind langlebig und mächtig.
JWTs sind praktisch, erfordern aber Sorgfalt. Verstehe, was sie enthalten, verifiziere Signaturen richtig, setze kurze Ablaufzeiten und lege niemals sensible Daten in den Payload.