Über jwt

JSON-basierter Standard für die Weitergabe von Ansprüchen zwischen Parteien in Webanwendungsumgebungen

JSON Web Token ( JWT , vorgeschlagene Aussprache, wie das Wort "jot" ^[1] ) ist ein vorgeschlagener Internetstandard zum Erstellen von Daten mit optionaler Signatur und/oder optionaler Verschlüsselung, deren Nutzlast JSON enthält, das eine bestimmte Anzahl von Ansprüchen geltend macht. Die Token werden entweder mit einem privaten Geheimnis oder einem öffentlichen/privaten Schlüssel signiert.

Ein Server könnte z. B. ein Token mit dem Anspruch "Als Administrator angemeldet" generieren und dieses Token einem Client zur Verfügung stellen. Der Client könnte dann dieses Token verwenden, um nachzuweisen, dass er als Administrator angemeldet ist. Die Token können mit dem privaten Schlüssel einer Partei (in der Regel dem des Servers) signiert werden, so dass jede Partei anschließend überprüfen kann, ob das Token legitim ist. Wenn die andere Partei, durch eine geeignete und vertrauenswürdige Mittel, im Besitz des entsprechenden öffentlichen Schlüssels ist, sind auch sie in der Lage, die Legitimität des Tokens zu überprüfen. Die Token sind so konzipiert, dass sie kompakt, ^[2] URL-sicher, ^[3] und verwendbar sind, insbesondere im Kontext von Webbrowsern mit einmaligem Anmelden (SSO). JWT-Ansprüche können in der Regel verwendet werden, um die Identität authentifizierter Benutzer zwischen einem Identitätsanbieter und einem Dienstanbieter zu übergeben, oder um einen anderen Typ von Ansprüchen zu übergeben, der von Geschäftsprozessen benötigt wird. ^{[4] [5]}

JWT stützt sich auf andere JSON-basierte Standards: JSON Web Signature und JSON Web Encryption. ^{[1] [6] [7]}

Structure

Header

Gibt an, welcher Algorithmus zum Generieren der Signatur verwendet wird. Im folgenden Beispiel wird angegeben, dass dieses Token signiert mit HMAC-SHA256.

Typische verwendete kryptographische Algorithmen sind HMAC mit SHA-256 (HS256) und RSA-Signatur mit SHA-256 (RS256). JWA (JSON Web Algorithms) RFC 7518 führt viele weitere für die Authentifizierung und Verschlüsselung ein. ^[8]

{"alg":"HS256","typ":"JWT"}

Payload

Enthält eine Reihe von Ansprüchen. Die JWT-Spezifikation definiert sieben registrierte Anspruchsnamen, bei denen es sich um die Standardfelder handelt, die üblicherweise in Token enthalten sind. ^[1] Benutzerdefinierte Ansprüche sind in der Regel auch enthalten, abhängig vom Zweck des Tokens.

Dieses Beispiel verfügt über den standardmäßigen Anspruch "Ausgestellt zum Zeitpunkt" () und einen benutzerdefinierten Anspruch ().

{"loggedInAs":"admin","iat":1422779638}

Sichere Signatur

Validiert das Token. Die Signatur wird berechnet, indem der Header und die Nutzlast mit Base64url EncodingRFC 4648 codiert und mit einem Punkttrennzeichen verkettet werden. Diese Zeichenfolge wird dann durch den kryptografischen Algorithmus geführt, der im Header angegeben ist. In diesem Beispiel wird HMAC-SHA256 mit einem gemeinsamen geheimen Schlüssel verwendet (Public-Key-Algorithmen sind ebenfalls definiert). Die Base64url-Codierung ähnelt base64, verwendet jedoch andere nicht-alphanumerische Zeichen und lässt den Abstand aus.

HMAC_SHA256(secret,base64urlEncoding(header)+'.'+base64urlEncoding(payload))

Die drei Teile werden separat mit Base64url EncodingRFC 4648 codiert und mit Punkten verkettet, um das JWT zu erzeugen:

Die obigen Daten und das Geheimnis von "secretkey" erstellt das Token:

(Die obigen JSON-Zeichenfolgen werden ohne Zeilenumbrüche oder Leerzeichen in UTF-8-Byte-Arrays formatiert. Dies ist wichtig, da sich selbst geringfügige Änderungen in den Daten auf das resultierende Token auswirken.)

Dieses resultierende Token kann problemlos an HTML und HTTP übergeben werden. ^[3]

Verwendung

Bei der Authentifizierung wird bei erfolgreicher Anmeldung eines Benutzers häufig ein JSON Web Token (JWT) zurückgegeben. Dieses Token sollte mithilfe eines sicheren Mechanismus wie . Es wird davon abgeraten, das JWT lokal in Browser-Speichermechanismen wie lokalem oder Sitzungsspeicher zu speichern. Bei unbeaufsichtigten Prozessen kann sich der Client auch direkt authentifizieren, indem er sein eigenes JWT mit einem vorab freigegebenen geheimen Schlüssel generiert und signiert und es wie folgt an einen OAuth-kompatiblen Dienst übergibt:

Wenn der Client eine gültige JWT-Assertion übergibt, generiert der Server eine access_token, die für Aufrufe der Anwendung gültig ist, und gibt sie an den Client zurück:

Wenn der Client auf eine geschützte Route oder Ressource zugreifen möchte, sollte der Benutzeragent das JWT senden, typischerweise im HTTP-Header unter Verwendung des Schemas. Der Inhalt des Headers könnte wie folgt aussehen:

Hierbei handelt es sich um einen zustandslosen Authentifizierungsmechanismus, da der Benutzerstatus nie im Serverspeicher gespeichert wird. Die geschützten Routen des Servers prüfen, ob im Authorization-Header ein gültiges JWT vorhanden ist, und ob dies der Fall ist vorhanden ist, kann der Benutzer auf geschützte Ressourcen zugreifen. Da JWTs in sich geschlossen sind, sind alle notwendigen Informationen vorhanden, sodass die Datenbank nicht mehrfach abgefragt werden muss.

Standardfelder

Eine Liste der aktuell registrierten Anspruchsnamen kann wie folgt lauten: bezogen von IANA JSON Web Token Claims Registry ^[11] .

Implementierungen

JWT-Implementierungen gibt es für viele Sprachen und Frameworks, einschließlich, aber nicht beschränkt auf:

Schwachstellen

JSON-Web-Token können den Sitzungsstatus enthalten. Wenn die Projektanforderungen jedoch eine Invalidierung der Sitzung vor Ablauf von JWT zulassen, können Dienste Tokenassertionen allein durch das Token nicht mehr vertrauen. Um zu überprüfen, ob die im Token gespeicherte Sitzung nicht widerrufen wird, müssen Tokenassertionen mit einem Datenspeicher abgeglichen werden. Dadurch werden die Token nicht mehr zustandslos, was den primären Vorteil von JWTs untergräbt. ^[37]

Der Sicherheitsberater Tim McLean berichtete über Schwachstellen in einigen JWT-Bibliotheken, die das Feld zur falschen Validierung von Token verwendeten, am häufigsten durch das Akzeptieren eines Tokens. Während diese Schwachstellen gepatcht wurden, McLean schlug vor, das Feld ganz abzulehnen, um ähnliche Verwirrung bei der Implementierung zu vermeiden. ^[10] Dennoch werden immer noch neue Schwachstellen in freier Wildbahn gefunden, wobei vier CVEs, die im Zeitraum 2018-2021 eingereicht wurden, diese Ursache haben. ^{[38] [ bessere Quelle benötigt ]}

Mit dem richtigen Design können Entwickler Algorithmus-Schwachstellen beheben, indem sie Vorsichtsmaßnahmen treffen: ^{[39] [40]}

1. Lassen Sie niemals den JWT-Header allein die Verifizierung vorantreiben
2. Kennen Sie die Algorithmen (vermeiden Sie es, nur vom Feld abhängig zu sein)
3. Verwenden Sie eine geeignete Schlüsselgröße

Im Jahr 2017 wurde festgestellt, dass mehrere JWT-Bibliotheken anfällig für einen ungültigen Angriff mit elliptischen Kurven sind. ^[41]

Einige haben argumentiert, dass JSON-Web-Token schwer zu verwenden sind aufgrund der vielen verschiedenen Verschlüsselungsalgorithmen und -optionen, die im Standard verfügbar sind, sicher und dass stattdessen alternative Standards sowohl für Web-Frontends ^[42] als auch für Backends verwendet werden sollten. ^[43]

Siehe auch

Referenzen

• RFC 7519
• jwt.io – spezialisierte Website über JWT mit Tools und Dokumentation, gepflegt von Auth0