Einführung in die JSON-Web-Token

NEU: Holen Sie sich die JWT-Handbuch für freie und lernen JWTs in der Tiefe!

Was ist JSON-Web-Token?

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

Obwohl JWTs verschlüsselt werden können, um auch die Geheimhaltung zwischen den Parteien zu gewährleisten, konzentrieren wir uns auf signierte Token. Signierte Token können die Integrität der darin enthaltenen Ansprüche überprüfen, während verschlüsselte Token diese Ansprüche vor anderen Parteien verbergen. Wenn Token mit öffentlichen/privaten Schlüsselpaaren signiert werden, bestätigt die Signatur auch, dass nur die Partei, die den privaten Schlüssel hält, derjenige ist, der ihn signiert hat.

Wann sollten Sie JSON-Web-Token verwenden?

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

• Autorisierung: Dies ist das häufigste Szenario für die Verwendung von JWT., Sobald der Benutzer angemeldet ist, enthält jede nachfolgende Anforderung die JWT, sodass der Benutzer auf Routen, Dienste und Ressourcen zugreifen kann, die mit diesem Token zulässig sind. Single Sign On ist eine Funktion, die JWT heutzutage aufgrund ihres geringen Overheads und ihrer einfachen Verwendung in verschiedenen Domänen häufig verwendet.

• Informationsaustausch: JSON-Web-Token sind eine gute Möglichkeit, Informationen zwischen Parteien sicher zu übertragen. Da JWTs signiert werden können—zum Beispiel mit öffentlichen / privaten Schlüsselpaaren-können Sie sicher sein, dass die Absender sind, wer sie sagen, sie sind., Da die Signatur mithilfe des Headers und der Nutzlast berechnet wird, können Sie außerdem überprüfen, ob der Inhalt nicht manipuliert wurde.

Was ist die JSON-Web-Token-Struktur?

In seiner kompakten Form bestehen JSON-Web-Token aus drei durch Punkte getrennten Teilen (.), die sind:

• Header
• Payload
• Signatur

Daher sieht ein JWT normalerweise wie folgt aus.

xxxxx.yyyyy.zzzzz

Lassen Sie uns brechen die verschiedenen Teile.,

Header

Der Header besteht typischerweise aus zwei Teilen: dem Typ des Tokens, der JWT ist, und dem verwendeten Signaturalgorithmus wie HMAC SHA256 oder RSA.

Zum Beispiel:

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

Dann ist dieser JSON Base64Url codiert, um den ersten Teil des JWT zu bilden.

Nutzlast

Der zweite Teil des Tokens ist die Nutzlast, die die Ansprüche enthält. Ansprüche sind Aussagen über eine Entität (in der Regel der Benutzer) und zusätzliche Daten.Es gibt drei Arten von Ansprüchen: registrierte, öffentliche und private Ansprüche.,

• Registrierte Ansprüche: Dies sind eine Reihe vordefinierter Ansprüche, die nicht obligatorisch, aber empfohlen sind, um eine Reihe nützlicher, interoperabler Ansprüche bereitzustellen. Einige von ihnen sind: iss (Emittent), exp (Ablaufzeit), Sub (Subjekt), aud (Publikum) und andere.

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

• Öffentliche Ansprüche: Diese können nach Belieben von JWTs-Benutzern definiert werden., Um Kollisionen zu vermeiden, sollten sie jedoch in der IANA JSON Web Token Registry definiert oder als URI definiert werden, der einen kollisionsresistenten Namespace enthält.

• Private Ansprüche: Dies sind die benutzerdefinierten Ansprüche, die erstellt wurden, um Informationen zwischen Parteien auszutauschen, die sich auf deren Verwendung einigen und weder registrierte noch öffentliche Ansprüche sind.

Eine Beispielnutzlast könnte sein:

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

Die Nutzlast wird dann Base64Url codiert, um den zweiten Teil des JSON-Web-Tokens zu bilden.,

Beachten Sie, dass diese Informationen für signierte Token zwar vor Manipulationen geschützt sind, aber von jedem lesbar sind. Geben Sie keine geheimen Informationen in die Nutzlast oder Header-Elemente eines JWT ein, es sei denn, sie sind verschlüsselt.

Signatur

Um den Signaturteil zu erstellen, müssen Sie den codierten Header, die codierte Nutzlast, ein Geheimnis, den im Header angegebenen Algorithmus und signieren.,

Wenn Sie beispielsweise 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 überprüfen, ob die Nachricht auf dem Weg nicht geändert wurde, und im Fall von Token, die mit einem privaten Schlüssel signiert sind, kann sie auch überprüfen, ob der Absender des JWT derjenige ist, von dem sie sagt, dass er es ist.

Alles zusammensetzen

Die Ausgabe besteht aus drei Base64-URL-Zeichenfolgen, die durch Punkte getrennt sind und in HTML-und HTTP-Umgebungen problemlos übergeben werden können, während sie im Vergleich zu XML-basierten Standards wie SAML kompakter sind.,

Im Folgenden wird ein JWT angezeigt, bei dem der vorherige Header und die Payload codiert und mit einem Secret signiert sind.

Wenn Sie mit JWT spielen und diese Konzepte in die Praxis umsetzen möchten, können Sie Folgendes verwenden jwt.io Debugger zum Dekodieren, Überprüfen und Generieren von JWTs.

Wie funktionieren JSON-Web-Token?

Wenn sich der Benutzer bei der Authentifizierung erfolgreich mit seinen Anmeldeinformationen anmeldet, wird ein JSON-Web-Token zurückgegeben. Da Token Anmeldeinformationen sind, muss sehr darauf geachtet werden, Sicherheitsprobleme zu vermeiden., Im Allgemeinen sollten Sie Token nicht länger als erforderlich aufbewahren.

Aus Sicherheitsgründen sollten Sie auch keine sensiblen Sitzungsdaten im Browserspeicher speichern.

Wenn der Benutzer auf eine geschützte Route oder Ressource zugreifen möchte, sollte der Benutzeragent die JWT senden, normalerweise im Autorisierungsheader unter Verwendung des Bearer-Schemas. Der Inhalt des Headers sollte wie folgt aussehen:

Authorization: Bearer <token>

Dies kann in bestimmten Fällen ein zustandsloser Autorisierungsmechanismus sein., Die geschützten Routen des Servers suchen im Header Authorization nach einem gültigen JWT, und wenn er vorhanden ist, kann der Benutzer auf geschützte Ressourcen zugreifen. Wenn das JWT die erforderlichen Daten enthält, kann die Notwendigkeit, die Datenbank nach bestimmten Vorgängen abzufragen, verringert werden, obwohl dies möglicherweise nicht immer der Fall ist.

Wenn das Token im Header Authorization gesendet wird, ist die Cross-Origin-Ressourcenfreigabe (CORS) kein Problem, da keine Cookies verwendet werden.,

Das folgende Diagramm zeigt, wie ein JWT abgerufen und für den Zugriff auf APIs oder Ressourcen verwendet wird:

1. Die Anwendung oder der Client fordert die Autorisierung an den Autorisierungsserver an. Dies wird über einen der verschiedenen Autorisierungsflüsse durchgeführt. Eine typische OpenID Connect-kompatible Webanwendung durchläuft beispielsweise den Endpunkt /oauth/authorize mithilfe des Autorisierungscodeflusses.
2. Wenn die Autorisierung erteilt wird, gibt der Autorisierungsserver ein Zugriffstoken an die Anwendung zurück.,
3. Die Anwendung verwendet das Zugriffstoken, um auf eine geschützte Ressource (wie eine API) zuzugreifen.

Beachten Sie, dass bei signierten Token alle im Token enthaltenen Informationen Benutzern oder anderen Parteien zugänglich gemacht werden, obwohl sie diese nicht ändern können. Dies bedeutet, dass Sie keine geheimen Informationen in das Token einfügen sollten.

Warum sollten wir JSON-Web-Token verwenden?

Lassen Sie uns über die Vorteile von JSON Web Tokens (JWT) im Vergleich zu einfachen Web Tokens (SWT) und Security Assertion Markup Language Tokens (SAML) sprechen.,

Da JSON weniger ausführlich als XML ist, ist seine Größe auch kleiner, was JWT kompakter als SAML macht, wenn es codiert ist. Dies macht JWT zu einer guten Wahl, um in HTML-und HTTP-Umgebungen übergeben zu werden.

Sicherheitstechnisch kann SWT nur mit dem HMAC-Algorithmus symmetrisch von einem gemeinsam genutzten Secret signiert werden. JWT-und SAML-Token können jedoch ein öffentliches/privates Schlüsselpaar in Form eines X. 509-Zertifikats zum Signieren verwenden. Das Signieren von XML mit der digitalen XML-Signatur ohne die Einführung obskurer Sicherheitslücken ist im Vergleich zur Einfachheit des Signierens von JSON sehr schwierig.,

JSON-Parser sind in den meisten Programmiersprachen üblich, da sie direkt Objekten zugeordnet werden. Umgekehrt verfügt XML nicht über eine natürliche Zuordnung von Dokument zu Objekt. Dies erleichtert die Arbeit mit JWT als mit SAML-Assertionen.

In Bezug auf die Nutzung wird JWT im Internet-Maßstab verwendet. Dies unterstreicht die einfache clientseitige Verarbeitung des JSON-Web-Tokens auf mehreren Plattformen, insbesondere auf Mobilgeräten.,

Vergleich der Länge eines codierten JWT und einer codierten SAML

Wenn Sie mehr über JSON-Web-Token lesen und diese sogar für die Authentifizierung in Ihren eigenen Anwendungen verwenden möchten, navigieren Sie zur Zielseite des JSON-Web-Tokens unter Auth0.