7. Creating and Validating JWTs (Erstellen und Validieren von JWTs)

7.1. Creating a JWT (Erstellen eines JWT)

Um ein JWT zu erstellen, werden die folgenden Schritte ausgeführt. Die Reihenfolge der Schritte ist in Fällen nicht signifikant, in denen keine Abhängigkeiten zwischen den Ein- und Ausgaben der Schritte bestehen.

1. Erstellen Sie ein JWT Claims Set, das die gewünschten Ansprüche enthält. Beachten Sie, dass Leerzeichen in der Darstellung ausdrücklich erlaubt sind und vor der Kodierung keine Kanonisierung durchgeführt werden muss.

2. Seien Sie die Nachricht (Message) die Oktette der UTF-8-Darstellung des JWT Claims Set.

3. Erstellen Sie einen JOSE Header, der den gewünschten Satz von Header-Parametern enthält. Das JWT muss (MUST) entweder der [JWS]- oder [JWE]-Spezifikation entsprechen. Beachten Sie, dass Leerzeichen in der Darstellung ausdrücklich erlaubt sind und vor der Kodierung keine Kanonisierung durchgeführt werden muss.

4. Je nachdem, ob das JWT ein JWS oder JWE ist, gibt es zwei Fälle:

   • Wenn das JWT ein JWS ist, erstellen Sie ein JWS unter Verwendung der Nachricht als JWS Payload; alle in [JWS] für die Erstellung eines JWS angegebenen Schritte müssen befolgt werden (MUST).

   • Andernfalls, wenn das JWT ein JWE ist, erstellen Sie ein JWE unter Verwendung der Nachricht als Klartext für das JWE; alle in [JWE] für die Erstellung eines JWE angegebenen Schritte müssen befolgt werden (MUST).

5. Wenn eine verschachtelte Signierungs- oder Verschlüsselungsoperation durchgeführt wird, sei die Nachricht das JWS oder JWE, und kehren Sie zu Schritt 3 zurück, wobei Sie einen "cty" (content type) Wert von "JWT" in dem in diesem Schritt erstellten neuen JOSE Header verwenden.

6. Andernfalls sei das resultierende JWT das JWS oder JWE.

7.2. Validating a JWT (Validieren eines JWT)

Bei der Validierung eines JWT werden die folgenden Schritte ausgeführt. Die Reihenfolge der Schritte ist in Fällen nicht signifikant, in denen keine Abhängigkeiten zwischen den Ein- und Ausgaben der Schritte bestehen. Wenn einer der aufgelisteten Schritte fehlschlägt, dann muss das JWT abgelehnt werden (MUST) - das heißt, von der Anwendung als ungültige Eingabe behandelt werden.

1. Überprüfen Sie, dass das JWT mindestens ein Punkt-Zeichen ('.') enthält.

2. Sei der kodierte JOSE Header der Teil des JWT vor dem ersten Punkt-Zeichen ('.').

3. Base64url-dekodieren Sie den kodierten JOSE Header unter der Einschränkung, dass keine Zeilenumbrüche, Leerzeichen oder andere zusätzliche Zeichen verwendet wurden.

4. Überprüfen Sie, dass die resultierende Oktett-Sequenz eine UTF-8-kodierte Darstellung eines vollständig gültigen JSON-Objekts ist, das RFC 7159 [RFC7159] entspricht; sei der JOSE Header dieses JSON-Objekt.

5. Überprüfen Sie, dass der resultierende JOSE Header keine doppelten Header-Parameter-Namen enthält. Bei Verwendung eines JSON-Parsers, der nur den lexikalisch letzten doppelten Member-Namen zurückgibt, wie in Abschnitt 15.12 von ECMAScript 5.1 [ECMAScript] angegeben, kann dieser Schritt automatisch erreicht werden.

6. Bestimmen Sie, ob das JWT ein JWS oder ein JWE ist, indem Sie den "enc" (encryption algorithm) Header-Parameter im JOSE Header überprüfen.

   • Wenn der "enc" Header-Parameter vorhanden ist, ist das JWT ein JWE.

   • Andernfalls ist das JWT ein JWS.

7. Je nachdem, ob das JWT ein JWS oder JWE ist, gibt es zwei Fälle:

   • Wenn das JWT ein JWS ist, befolgen Sie die in [JWS] angegebenen Schritte zur Validierung eines JWS unter Verwendung des Algorithmus im JOSE Header und des Schlüssels sowie des JWS Payload und der JWS Signature. Sei die Nachricht das JWS Payload.

   • Andernfalls, wenn das JWT ein JWE ist, befolgen Sie die in [JWE] angegebenen Schritte zur Validierung eines JWE unter Verwendung des Algorithmus im JOSE Header und des Schlüssels. Sei die Nachricht der Klartext, der aus der Entschlüsselung resultiert.

8. Wenn der JOSE Header einen "cty" (content type) Header-Parameter mit einem Wert von "JWT" enthält, dann ist das JWT ein verschachteltes JWT (Nested JWT). In diesem Fall kehren Sie zu Schritt 1 zurück und verwenden die Nachricht als JWT.

9. Andernfalls base64url-dekodieren Sie die Nachricht unter der Einschränkung, dass keine Zeilenumbrüche, Leerzeichen oder andere zusätzliche Zeichen verwendet wurden.

10. Überprüfen Sie, dass die resultierende Oktett-Sequenz eine UTF-8-kodierte Darstellung eines vollständig gültigen JSON-Objekts ist, das RFC 7159 [RFC7159] entspricht; sei das JWT Claims Set dieses JSON-Objekt.

11. Überprüfen Sie, dass das JWT Claims Set keine doppelten Anspruchsnamen enthält. Bei Verwendung eines JSON-Parsers, der nur den lexikalisch letzten doppelten Member-Namen zurückgibt, wie in Abschnitt 15.12 von ECMAScript 5.1 [ECMAScript] angegeben, kann dieser Schritt automatisch erreicht werden.

Beachten Sie schließlich, dass, wenn einer Anwendung mehrere Schlüssel zur Verfügung stehen, sie möglicherweise versucht, ein JWS oder JWE mehrmals mit verschiedenen Schlüsseln zu validieren. Wenn die Anwendung feststellt, dass der Fehler auf die Verwendung eines bestimmten Schlüssels zurückzuführen war, kann sie weiterhin andere Schlüssel ausprobieren, bis sie erfolgreich ist oder alle Schlüssel erschöpft sind.

7.3. String Comparison Rules (String-Vergleichsregeln)

Die Verarbeitung eines JWT erfordert den Vergleich von JSON-String-Werten.

Vergleiche von Anspruchsnamen und Header-Parameter-Namen werden immer als groß-/kleinschreibungsempfindliche String-Vergleiche ohne Typkonvertierung durchgeführt.

Vergleiche von URIs in StringOrURI-Werten und JSON-String-Werten werden wie folgt durchgeführt:

• Wenn ein Wert ein URI ist und der andere kein URI ist, sind die beiden Werte unterschiedlich.

• Wenn beide Werte URIs sind, werden sie unter Verwendung eines groß-/kleinschreibungsempfindlichen String-Vergleichs ohne Typkonvertierung, Kanonisierung oder Verarbeitung von Backslash-Escapes verglichen.

• Wenn keiner der Werte ein URI ist, werden sie unter Verwendung eines groß-/kleinschreibungsempfindlichen String-Vergleichs ohne Typkonvertierung oder Verarbeitung von Backslash-Escapes verglichen.

Beachten Sie, dass für jeden gegebenen Anwendungsfall lockerere oder strengere Vergleichsregeln für URIs und andere Strings angemessen sein können, aber diese Vergleichsregeln müssen (MUST) explizit spezifiziert werden.

---