JWT (JSON Web Token) ist ein kompaktes Format zur Übertragung signierter Daten, meist Informationen über einen authentifizierten Nutzer. Ein Token besteht aus drei durch Punkte getrennten Teilen: header.payload.signature. In deutschen Unternehmen läuft die Diskussion um JWT selten ohne die Frage, was davon aus Sicht der DSGVO überhaupt in den Payload darf.
Umlaute im Payload und die DSGVO-Frage
Ein Payload wie {"name": "Jürgen Müller", "stadt": "Nürnberg"} wird ganz normal in Base64URL kodiert – das Verfahren arbeitet auf UTF-8-Bytes, unabhängig von Umlauten oder ß. Der eigentlich diskussionswürdige Punkt ist ein anderer: Ein JWT mit Namen, E-Mail oder Rolle ist personenbezogene Daten im Sinne der DSGVO, und viele deutsche Unternehmen legen deshalb bewusst nur eine User-ID statt Klartextdaten in den Payload, um die Verarbeitung schlanker prüfbar zu halten.
Die drei Teile eines Tokens
- Header – ein JSON mit Token-Typ und Signaturalgorithmus (z. B. HS256 oder RS256), Base64URL-kodiert.
- Payload – ein JSON mit „Claims": Nutzerdaten, Ausstellungszeitpunkt, Ablaufdatum usw., ebenfalls Base64URL-kodiert.
- Signature – eine über Header und Payload berechnete Signatur mit geheimem oder privatem Schlüssel, die bestätigt, dass der Token nicht verändert wurde.
Base64URL, nicht normales Base64
JWT verwendet eine URL-sichere Variante von Base64: Die Zeichen + und / werden durch - und _ ersetzt, und das Füllzeichen = wird meist weggelassen. So lässt sich ein Token ohne zusätzliche Kodierung direkt in eine URL oder einen Header einsetzen.
Ein wichtiger Unterschied: Dekodieren ≠ Verifizieren
Header und Payload sind nur Base64URL – jeder kann sie ohne Schlüssel dekodieren und lesen. Das Dekodieren eines Tokens beweist nicht, dass die Daten unverändert sind. Man kann dem Inhalt eines Tokens erst vertrauen, nachdem seine Signatur mit dem passenden Schlüssel geprüft wurde – und diese Prüfung übernimmt der Server, nicht ein Client, der nur hineinschaut.
Gefährlicher Angriff: Algorithmus-Verwechslung mit „none"
Die JWT-Spezifikation erlaubt den Algorithmus none – einen Token ohne Signatur. Vertraut ein Backend naiv dem Feld alg aus dem Header des Tokens, anstatt die Signatur gegen einen festen, vorab bekannten Algorithmus zu prüfen, kann ein Angreifer alg auf none setzen, die Signatur entfernen – und der Token besteht die Prüfung mit beliebigen Daten. Zuverlässige JWT-Bibliotheken verlangen bei der Verifizierung die explizite Angabe des erwarteten Algorithmus.
Spring Security und die deutsche Enterprise-Landschaft
In deutschen Konzernen und im öffentlichen Sektor dominiert häufig Java mit Spring Security als Grundlage für JWT-basierte Authentifizierung, oft eingebettet in eine Keycloak-Instanz für Single Sign-on über mehrere interne Anwendungen hinweg. Gerade in solchen Umgebungen mit mehreren Identity-Providern ist die Prüfung, welcher iss (Issuer) und welche aud (Audience) im Token stehen, mindestens so wichtig wie die reine Signaturprüfung.