Viele halten ein JWT (JSON Web Token) für einen versiegelten Umschlag. Dabei sind Header und Payload für jeden lesbar, der das Token besitzt.

Einem JWT begegnet man als Header der Form Authorization: Bearer, gefolgt vom Token, sobald eine API nach einem Login verlangt. Wer nicht weiß, was darin steht, legt unbemerkt Geheimnisse in den Payload offen.

Ein JWT ist ein Zugriffstoken aus drei Teilen, die mit Punkten verbunden sind: Header, Payload und Signatur. Alle drei sind Base64url-kodiert, also in druckbare Zeichen umgewandelt – das ist eine Kodierung, keine Verschlüsselung, und lässt sich ohne Schlüssel sofort zurückübersetzen.

Der Header ist ein JSON-Objekt mit Metadaten, vor allem dem Signaturverfahren im Feld alg. Die Payload ist ebenfalls JSON und enthält Claims, also Angaben wie Nutzerkennung oder Ablaufzeitpunkt. Der Claim exp gibt den Ablaufzeitpunkt als Unix-Zeit an, iat die Ausstellungszeit. Das Token an den Punkten trennen und die ersten beiden Teile zurückübersetzen: Nutzerkennung und Rollen stehen im Klartext. Die Signatur entsteht, weil der Aussteller Header und Payload mit einem nur ihm bekannten Schlüssel signiert. Ändert jemand die Payload, passt die Signatur nicht mehr – der Prüfer verwirft das Token.

Verwechselt wird das mit Verschlüsselung: Die Signatur macht kein Geheimnis aus dem Inhalt, sie belegt nur, dass genau dieser Aussteller genau diesen Inhalt erzeugt hat. Der Prüfer gibt nach RFC 8725 den Algorithmus fest vor und lehnt none ab.

Ein JWT ist kein Briefumschlag, sondern eine unterschriebene Postkarte: Inhalt offen lesbar, Absender beglaubigt. Deshalb gehören Passwörter und Geheimnisse nie in die Payload.

📌 Base64url · Claims · Signatur

📚 Webentwicklung von Grund auf · Tag 4 von 30
#WebSecurity #api #backend #webdev