JWT legt Claims in ein signiertes Token, sodass ein Server ohne Session-Speicher verifizieren kann

Wenn sich ein Benutzer anmeldet, erzeugt der Server üblicherweise eine Session-ID und speichert den Benutzer in einer Tabelle; jede Anfrage greift dann auf diese Tabelle zu. Das funktioniert auf einer einzelnen Maschine, aber eine Flotte zustandsloser API-Server kann eine In-Memory-Tabelle nicht ohne Cache oder Sticky Sessions gemeinsam nutzen.

JWT verlagert die Claims des Benutzers in das Token selbst. Das Token ist eine kompakte, URL-sichere JSON-Nutzlast, die signiert ist, sodass sie nicht gefälscht werden kann. Der Server prüft die Signatur und liest die Claims direkt aus dem Token.

Das Ergebnis ist zustandslose Authentifizierung: Jeder Server, der den öffentlichen Schlüssel kennt, kann jeden Benutzer ohne gemeinsamen Session-Speicher verifizieren. Die Claims und der Nachweis reisen zusammen, weshalb JWT zum Standard für API-Authentifizierung und Single Sign-on wurde.

Lege die Claims in das Token; die Signatur ist der Nachweis.

Weil das Token in sich geschlossen ist, benötigt ein Verifizierer keinen Datenbankaufruf, sodass der Anfragepfad flach und schnell bleibt.

Die Signatur, nicht die Session, ist der Vertrauensanker, sodass jeder zustandslose Server mit dem Schlüssel jedes Token verifizieren kann.

Seine dreiteilige Struktur header.payload.signature ist für jede Sprache in einem Web-Ökosystem einfach zu implementieren.

Es lässt sich mit OAuth und OpenID Connect kombinieren, sodass dasselbe Token über viele Dienste und Produkte hinweg funktioniert.

Wenn der Nachweis mit dem Claim reist, kann man überall verifizieren und den Verifizierer horizontal skalieren, weil die Identität in sich geschlossen wird statt zu einem Nachschlagevorgang.

JWT wurde im Mai 2015 als RFC 7519 standardisiert, samt einer JWS/JWE-Familie. Es wurde zum Standard für die Authentifizierung von Single-Page-Apps, API-Gateways und Microservices. Seine bekannten Schwächen sind die Widerrufbarkeit (ein Token kann vor dem Ablauf ohne Denylist nicht ungültig gemacht werden) und Fehler durch Algorithmus-Verwechslung, dazu Größen-Overhead gegenüber opaken Sessions.