Starten Sie mit JSON-Web-Token

JSON-Web-Token (JWT) ist ein offener Standard (RFC 7519), der eine kompakte und in sich geschlossene Methode zur sicheren Übertragung von Informationen zwischen Parteien als JSON-Objekt definiert. Diese Informationen können überprüft und als vertrauenswürdig eingestuft werden, da sie digital signiert sind. JWTs können mit einem geheimen (mit HMAC-Algorithmus) oder einem öffentlichen/privaten Schlüsselpaar mit RSA signiert werden.

Lassen Sie uns einige Konzepte dieser Definition näher erläutern.

• Kompakt: Aufgrund seiner Größe kann das Token über eine URL, einen POST-Parameter oder innerhalb eines HTTP-Headers gesendet werden. Außerdem geht die Übertragung aufgrund seiner Größe sehr schnell.
• In sich geschlossen: Die Payload enthält alle erforderlichen Informationen über den Benutzer, damit die Datenbank nicht mehrmals abgefragt werden muss.

Dies sind einige Szenarien, in denen JSON-Web-Token nützlich sind:

• Authentifizierung: Dies ist das typische Szenario für die Verwendung von JWT. Sobald der Benutzer angemeldet ist, wird jede nachfolgende Anfrage das JWT enthalten, wodurch der Benutzer auf Routen, Dienste und Ressourcen zugreifen kann, die mit diesem Token zugelassen sind. Single Sign-on ist eine Funktion, bei der JWT heutzutage weit verbreitet ist, da der Aufwand gering ist und die Funktion problemlos zwischen Systemen verschiedener Domänen verwendet werden kann.
• Informationsaustausch: JWTs sind eine gute Möglichkeit, Informationen sicher zwischen Parteien zu übertragen, denn da sie signiert werden können, z. B. mit einem öffentlichen/privaten Schlüsselpaar, können Sie sicher sein, dass der Absender wirklich der ist, der er vorgibt zu sein. Da die Signatur anhand des Headers und der Payloads berechnet wird, können Sie außerdem überprüfen, ob sich der Inhalt nicht geändert hat.

JWTs bestehen aus drei Teilen, die durch Punkte (.) getrennt sind, und zwar:

• Header
• Payload
• Signatur

Daher sieht ein JWT normalerweise wie folgt aus:

xxxxx.yyyyy.zzzzz

Schauen wir uns die einzelnen Teile an.

Header

Der Header besteht typischerweise aus zwei Teilen: dem Typ des Token, also JWT, und dem Hashing-Algorithmus wie HMAC SHA256 oder RSA.

Zum Beispiel:

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

Anschließend wird dieses JSON mit Base64Url kodiert und bildet den ersten Teil des JWT.

Payload

Der zweite Teil des Token ist die Payload, die die Claims enthält. Claims sind Aussagen über eine Entität (in der Regel der Benutzer) und zusätzliche Metadaten. Es gibt drei Arten von Claims: reservierte, öffentliche und private Claims.

• • Reservierte Claims: Hierbei handelt es sich um eine Reihe vordefinierter Claims, die nicht obligatorisch sind, aber empfohlen werden, um eine Reihe nützlicher, interoperabler Claims bereitzustellen. Einige von ihnen sind: iss (Aussteller), exp (Verfallszeit), sub (Subjekt), aud (Publikum) und andere.

Beachten Sie, dass die Namen der Claims nur drei Zeichen lang sind, da JWT kompakt sein soll.

• Öffentliche Claims: Diese können von den Nutzern von JWTs nach Belieben definiert werden. Um Kollisionen zu vermeiden, sollten sie jedoch in der IANA JSON Web Token Registry definiert werden oder als URI definiert werden, die einen kollisionssicheren Namespace enthält.
• Private Claims: Dies sind die benutzerdefinierten Claims, die erstellt wurden, um Informationen zwischen Parteien auszutauschen, die sich auf ihre Verwendung einigen.

Ein Beispiel für eine Payload könnte sein:

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

Die Payload wird dann Base64Url kodiert und bildet den zweiten Teil des JWT.

Signatur

Um den Signaturteil zu erstellen, müssen Sie den kodierten Header, die kodierte Payload, ein Geheimnis und den im Header angegebenen Algorithmus nehmen und diesen signieren.

Wenn Sie zum Beispiel den HMAC SHA256-Algorithmus verwenden möchten, wird die Signatur folgendermaßen erstellt:

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

Die Signatur wird verwendet, um zu verifizieren, dass der Absender des JWT derjenige ist, für den er sich ausgibt, und um sicherzustellen, dass die Nachricht nicht auf irgendeine Weise verändert wurde.

Alles zusammenfügen

Das Ergebnis sind drei durch Punkte getrennte Base64-Strings, die problemlos in HTML- und HTTP-Umgebungen weitergegeben werden können und im Vergleich zu XML-basierten Standards wie SAML kompakter sind.

Im Folgenden sehen Sie ein JWT, bei dem der vorherige Header und die Payload verschlüsselt sind und das mit einem Geheimnis signiert ist.

Sie können jwt.io besuchen, wo Sie ein JWT ausprobieren und diese Konzepte in die Praxis umsetzen können. Mit jwt.io können Sie JWT dekodieren, verifizieren und generieren.

Bei der Authentifizierung wird ein JSON-Web-Token zurückgegeben, wenn sich der Benutzer erfolgreich mit seinen Anmeldedaten anmeldet. Da es sich bei Token um Anmeldedaten handelt, müssen Sie sehr vorsichtig sein, um Sicherheitsprobleme zu vermeiden. Im Allgemeinen sollten Sie Token nicht länger als nötig aufbewahren.

Sie sollten auch keine sensiblen Sitzungsdaten im Browserspeicher aufbewahren, da diese nicht sicher sind.

Wann immer der Benutzer auf eine geschützte Route zugreifen möchte, sollte er den JWT senden, typischerweise im Autorisierungs-Header unter Verwendung des Bearer-Schemas. Daher sollte der Inhalt des Headers wie folgt aussehen.

Autorisierung: Bearer <Token>

Dies ist ein zustandsloser Authentifizierungsmechanismus, da der Status des Benutzers niemals im Speicher des Servers gespeichert wird. Die geschützten Routen des Servers prüfen, ob im Autorisierungs-Header ein gültiges JWT enthalten ist, und wenn dies der Fall ist, wird der Benutzer zugelassen. Da JWTs in sich geschlossen sind, sind alle erforderlichen Informationen vorhanden, sodass nicht ständig zur Datenbank hin und her gewechselt werden muss.

So können Sie sich vollständig auf zustandslose Daten-APIs verlassen und sogar Anfragen an nachgelagerte Dienste stellen. Es spielt keine Rolle, welche Domänen Ihre APIs bedienen, da Cross-Origin Resource Sharing (CORS) kein Problem darstellt, da keine Cookies verwendet werden.

Lassen Sie uns über die Vorteile von JSON-Web-Token (JWT) sprechen und sie mit Simple-Web-Token (SWT) und Security Assertion Markup Language Token (SAML) vergleichen.

Da JSON weniger umfangreich ist als XML, ist seine Größe bei der Kodierung auch geringer, wodurch JWT kompakter ist als SAML. Das macht JWT zu einer guten Wahl für die Weitergabe in HTML- und HTTP-Umgebungen.

Aus Sicherheitsgründen kann SWT nur symmetrisch mit einem gemeinsamen Geheimnis unter Verwendung des HMAC-Algorithmus signiert werden. JWT- und SAML-Token können auch mit einem öffentlichen/privaten Schlüsselpaar in Form eines X.509-Zertifikats signiert werden. Es ist jedoch sehr schwierig, XML mit XML Digital Signature zu signieren, ohne dabei obskure Sicherheitslücken zu schaffen, verglichen mit der Einfachheit der Signierung von JSON.

JSON-Parser sind in den meisten Programmiersprachen üblich, da sie direkt auf Objekte abbilden, während XML keine natürliche Abbildung von Dokumenten auf Objekte hat. Das macht die Arbeit mit JWT einfacher als mit SAML-Assertions.

Was die Nutzung angeht, so wird JWT im gesamten Internet verwendet. Dies unterstreicht die Einfachheit der Client-seitigen Verarbeitung von JWTs auf verschiedenen Plattformen, insbesondere auf mobilen Geräten.

In Auth0 geben wir JWTs als Ergebnis des Authentifizierungsprozesses aus. Wenn sich der Benutzer mit Auth0 anmeldet, wird ein JWT erstellt, signiert und an den Benutzer gesendet. Auth0 unterstützt das Signieren von JWT sowohl mit HMAC- als auch mit RSA-Algorithmen. Dieses Token wird dann zur Authentifizierung und Autorisierung bei APIs verwendet, die Zugriff auf ihre geschützten Routen und Ressourcen gewähren.

Wir verwenden JWTs auch zur Authentifizierung und Autorisierung in der API v2 von Auth0 und ersetzen damit die herkömmliche Verwendung von regulären blickdichten API-Schlüsseln. Was die Autorisierung betrifft, so ermöglichen JSON-Web-Token eine granulare Sicherheit, d. h. die Möglichkeit, einen bestimmten Satz von Berechtigungen im Token zu spezifizieren, was die Fehlererkennung verbessert.