JSON Web Token (abgekürzt als JWT) ist derzeit die populärste domänenübergreifende Authentifizierungslösung. Dieser Artikel stellt seine Prinzipien und Verwendung vor.

I. Das Problem der domänenübergreifenden Authentifizierung

Internetdienste sind untrennbar mit der Benutzerauthentifizierung verbunden. Der allgemeine Prozess ist wie folgt:

Der Benutzer sendet den Benutzernamen und das Passwort an den Server.
Nachdem der Server die Daten erfolgreich verifiziert hat, speichert er relevante Daten in der aktuellen Sitzung, wie z. B. die Benutzerrolle, die Anmeldezeit usw.
Der Server sendet eine session_id an den Benutzer zurück und schreibt diese in das Cookie des Benutzers.
Bei jeder nachfolgenden Anfrage des Benutzers wird die session_id über das Cookie an den Server zurückgesendet.
Nach Erhalt der session_id findet der Server die zuvor gespeicherten Daten und kennt so die Identität des Benutzers. Das Problem bei diesem Modell ist, dass es eine schlechte Skalierbarkeit aufweist. Für eine einzelne Maschine gibt es kein Problem. Wenn es sich jedoch um einen Servercluster oder eine domänenübergreifende, serviceorientierte Architektur handelt, ist die gemeinsame Nutzung von Sitzungsdaten erforderlich, und jeder Server sollte in der Lage sein, die Sitzung zu lesen. Angenommen, Website A und Website B sind verwandte Dienste desselben Unternehmens. Nun ist es erforderlich, dass sich ein Benutzer, sobald er sich auf einer der Websites anmeldet, automatisch anmeldet, wenn er auf die andere Website zugreift. Wie lässt sich das erreichen? Eine Lösung besteht darin, die Sitzungsdaten persistent zu speichern und in eine Datenbank oder eine andere Persistenzschicht zu schreiben. Nach Erhalt von Anfragen fordern verschiedene Dienste Daten von der Persistenzschicht an. Der Vorteil dieser Lösung ist, dass die Architektur klar ist, der Nachteil jedoch, dass der Arbeitsaufwand relativ groß ist. Wenn die Persistenzschicht ausfällt, liegt zudem ein Single-Point-of-Failure vor. Eine andere Lösung besteht darin, dass der Server einfach keine Sitzungsdaten speichert. Alle Daten werden auf dem Client gespeichert und mit jeder Anfrage an den Server zurückgesendet. JWT ist ein Vertreter dieser Lösung.

II. Das Prinzip von JWT

Das Prinzip von JWT ist, dass der Server nach der Authentifizierung ein JSON-Objekt generiert und es an den Benutzer zurücksendet, wie dieses:

{"name": "Alice", "role": "admin", "expiration time": "0:00, July 1, 2024"}

Danach muss dieses JSON-Objekt bei jeder Kommunikation des Benutzers mit dem Server zurückgesendet werden. Der Server bestimmt die Identität des Benutzers ausschließlich anhand dieses Objekts. Um zu verhindern, dass der Benutzer die Daten manipuliert, fügt der Server beim Generieren dieses Objekts eine Signatur hinzu (Details werden später beschrieben). Der Server speichert keine Sitzungsdaten mehr. Das heißt, der Server wird zustandslos, was es einfacher macht, eine Erweiterung zu erreichen.

III. Die Datenstruktur von JWT

Das tatsächliche JWT sieht wahrscheinlich so aus:

Es ist eine sehr lange Zeichenkette, die durch Punkte (.) in drei Teile geteilt ist. Beachten Sie, dass sich innerhalb von JWT kein Zeilenumbruch befindet. Hier wird es zur einfachen Darstellung in mehreren Zeilen geschrieben. Die drei Teile von JWT sind wie folgt:

Header
Payload (Nutzlast)
Signature (Signatur) In einer Zeile geschrieben, sieht es so aus: Header.Payload.Signature Im Folgenden werden diese drei Teile der Reihe nach vorgestellt.

3.1 Header

Der Header-Teil ist ein JSON-Objekt, das die Metadaten von JWT beschreibt, normalerweise so: {"alg": "HS256", "typ": "JWT"} Im obigen Code steht das Attribut alg für den Signaturalgorithmus (algorithm), und der Standardwert ist HMAC SHA256 (geschrieben als HS256); das Attribut typ steht für den Typ dieses Tokens, und JWT-Token werden einheitlich als JWT geschrieben. Schließlich wird das obige JSON-Objekt mit dem Base64URL-Algorithmus in eine Zeichenkette umgewandelt (Details werden später beschrieben).

3.2 Payload

Der Payload-Teil ist ebenfalls ein JSON-Objekt, das zum Speichern der Daten verwendet wird, die tatsächlich übertragen werden müssen. JWT definiert 7 offizielle Felder zur Auswahl.

iss (issuer): Aussteller
exp (expiration time): Ablaufzeit
sub (subject): Betreff
aud (audience): Publikum
nbf (Not Before): Gültigkeitsbeginn
iat (Issued At): Ausstellungszeit
jti (JWT ID): Seriennummer Zusätzlich zu den offiziellen Feldern können Sie in diesem Teil auch private Felder definieren. Das folgende ist ein Beispiel:

{"sub": "1234567890", "name": "John Doe", "admin": true}

Beachten Sie, dass JWT standardmäßig nicht verschlüsselt ist und jeder es lesen kann. Geben Sie daher keine geheimen Informationen in diesem Teil an. Dieses JSON-Objekt muss ebenfalls mit dem Base64URL-Algorithmus in eine Zeichenkette umgewandelt werden.

3.3 Signature

Der Signature-Teil ist die Signatur der ersten beiden Teile, um Datenmanipulationen zu verhindern. Zunächst muss ein geheimer Schlüssel (secret) angegeben werden. Dieser Schlüssel ist nur dem Server bekannt und darf nicht an den Benutzer weitergegeben werden. Verwenden Sie dann den im Header angegebenen Signaturalgorithmus (der Standardwert ist HMAC SHA256), um die Signatur gemäß der folgenden Formel zu generieren:

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

Nach der Berechnung der Signatur kombinieren Sie die Header-, Payload- und Signature-Teile zu einer Zeichenkette, die durch "Punkte" (.) zwischen den einzelnen Teilen getrennt ist, und können sie dann an den Benutzer zurückgeben.

3.4 Base64URL

Wie bereits erwähnt, ist der Serialisierungsalgorithmus für Header und Payload Base64URL. Dieser Algorithmus ist dem Base64-Algorithmus im Wesentlichen ähnlich, es gibt jedoch einige kleine Unterschiede. Als Token kann JWT in einigen Fällen in einer URL platziert werden (z. B. api.example.com/?token = xxx). Die Base64 hat drei Zeichen +, / und =, die in der URL eine besondere Bedeutung haben, daher müssen sie ersetzt werden: = wird weggelassen, + wird durch - ersetzt und / wird durch _ ersetzt. Dies ist der Base64URL-Algorithmus.

IV. Die Verwendung von JWT

Nachdem der Client das vom Server zurückgegebene JWT erhalten hat, kann er es im Cookie oder im localStorage speichern. Danach muss der Client dieses JWT jedes Mal mitbringen, wenn er mit dem Server kommuniziert. Sie können es in das Cookie einfügen und automatisch senden, aber dies ist nicht domänenübergreifend möglich. Ein besserer Weg ist also, es in das Authorization-Feld des HTTP-Anforderungsheaders einzufügen.

Authorization: Bearer <token>

Eine andere Möglichkeit besteht darin, JWT bei domänenübergreifenden Anfragen in den Datenkörper der POST-Anfrage zu legen.

V. Einige Eigenschaften von JWT

(1) JWT ist standardmäßig nicht verschlüsselt, kann aber verschlüsselt werden. Nach der Generierung des ursprünglichen Tokens kann er mit einem geheimen Schlüssel erneut verschlüsselt werden.

(2) Wenn JWT nicht verschlüsselt ist, können keine geheimen Daten in JWT geschrieben werden.

(3) JWT kann nicht nur zur Authentifizierung, sondern auch zum Austausch von Informationen verwendet werden. Die effektive Verwendung von JWT kann die Anzahl der Datenbankabfragen des Servers reduzieren.

(4) Der größte Nachteil von JWT besteht darin, dass es unmöglich ist, ein bestimmtes Token während der Verwendung zu widerrufen oder die Berechtigungen des Tokens zu ändern, da der Server den Sitzungsstatus nicht speichert. Das heißt, sobald ein JWT ausgestellt wurde, ist es bis zum Ablauf gültig, es sei denn, der Server implementiert zusätzliche Logik.

(5) JWT selbst enthält Authentifizierungsinformationen. Sobald es durchsickert, kann jeder alle Berechtigungen des Tokens erhalten. Um Diebstahl zu reduzieren, sollte die Gültigkeitsdauer von JWT relativ kurz eingestellt werden. Für einige wichtigere Berechtigungen sollte der Benutzer bei der Verwendung erneut authentifiziert werden.

(6) Um Diebstahl zu reduzieren, sollte JWT nicht im Klartext über das HTTP-Protokoll übertragen werden, sondern über das HTTPS-Protokoll.