7. Creating and Validating JWTs (Création et validation des JWT)

7.1. Creating a JWT (Création d'un JWT)

Pour créer un JWT, les étapes suivantes sont effectuées. L'ordre des étapes n'est pas significatif dans les cas où il n'y a pas de dépendances entre les entrées et les sorties des étapes.

1. Créer un JWT Claims Set contenant les revendications souhaitées. Notez que les espaces blancs sont explicitement autorisés dans la représentation et aucune canonisation n'a besoin d'être effectuée avant l'encodage.

2. Soit le Message les octets de la représentation UTF-8 du JWT Claims Set.

3. Créer un JOSE Header contenant l'ensemble souhaité de paramètres d'en-tête. Le JWT doit (MUST) être conforme à la spécification [JWS] ou [JWE]. Notez que les espaces blancs sont explicitement autorisés dans la représentation et aucune canonisation n'a besoin d'être effectuée avant l'encodage.

4. Selon que le JWT est un JWS ou un JWE, il y a deux cas :

   • Si le JWT est un JWS, créer un JWS en utilisant le Message comme charge utile JWS ; toutes les étapes spécifiées dans [JWS] pour créer un JWS doivent (MUST) être suivies.

   • Sinon, si le JWT est un JWE, créer un JWE en utilisant le Message comme texte en clair pour le JWE ; toutes les étapes spécifiées dans [JWE] pour créer un JWE doivent (MUST) être suivies.

5. Si une opération de signature ou de chiffrement imbriquée sera effectuée, soit le Message le JWS ou JWE, et revenir à l'étape 3, en utilisant une valeur "cty" (content type) de "JWT" dans le nouveau JOSE Header créé à cette étape.

6. Sinon, soit le JWT résultant le JWS ou JWE.

7.2. Validating a JWT (Validation d'un JWT)

Lors de la validation d'un JWT, les étapes suivantes sont effectuées. L'ordre des étapes n'est pas significatif dans les cas où il n'y a pas de dépendances entre les entrées et les sorties des étapes. Si l'une des étapes listées échoue, alors le JWT doit être rejeté (MUST) -- c'est-à-dire, traité par l'application comme une entrée invalide.

1. Vérifier que le JWT contient au moins un caractère point ('.').

2. Soit l'en-tête JOSE encodé la portion du JWT avant le premier caractère point ('.').

3. Décoder en base64url l'en-tête JOSE encodé en suivant la restriction qu'aucun saut de ligne, espace blanc ou autre caractère supplémentaire n'a été utilisé.

4. Vérifier que la séquence d'octets résultante est une représentation encodée en UTF-8 d'un objet JSON complètement valide conforme au RFC 7159 [RFC7159] ; soit le JOSE Header cet objet JSON.

5. Vérifier que le JOSE Header résultant ne contient pas de noms de paramètres d'en-tête en double. Lors de l'utilisation d'un analyseur JSON qui ne renvoie que le dernier nom de membre en double lexicalement, comme spécifié dans la section 15.12 d'ECMAScript 5.1 [ECMAScript], cette étape peut être accomplie automatiquement.

6. Déterminer si le JWT est un JWS ou un JWE en examinant le paramètre d'en-tête "enc" (encryption algorithm) dans le JOSE Header.

   • Si le paramètre d'en-tête "enc" est présent, le JWT est un JWE.

   • Sinon, le JWT est un JWS.

7. Selon que le JWT est un JWS ou un JWE, il y a deux cas :

   • Si le JWT est un JWS, suivre les étapes spécifiées dans [JWS] pour valider un JWS en utilisant l'algorithme dans le JOSE Header et la clé, ainsi que la charge utile JWS et la signature JWS. Soit le Message la charge utile JWS.

   • Sinon, si le JWT est un JWE, suivre les étapes spécifiées dans [JWE] pour valider un JWE en utilisant l'algorithme dans le JOSE Header et la clé. Soit le Message le texte en clair résultant du déchiffrement.

8. Si le JOSE Header contient un paramètre d'en-tête "cty" (content type) avec une valeur de "JWT", alors le JWT est un JWT imbriqué. Dans ce cas, revenir à l'étape 1, en utilisant le Message comme JWT.

9. Sinon, décoder en base64url le Message en suivant la restriction qu'aucun saut de ligne, espace blanc ou autre caractère supplémentaire n'a été utilisé.

10. Vérifier que la séquence d'octets résultante est une représentation encodée en UTF-8 d'un objet JSON complètement valide conforme au RFC 7159 [RFC7159] ; soit le JWT Claims Set cet objet JSON.

11. Vérifier que le JWT Claims Set ne contient pas de noms de revendications en double. Lors de l'utilisation d'un analyseur JSON qui ne renvoie que le dernier nom de membre en double lexicalement, comme spécifié dans la section 15.12 d'ECMAScript 5.1 [ECMAScript], cette étape peut être accomplie automatiquement.

Enfin, notez que lorsque plusieurs clés sont disponibles pour une application, elle peut tenter de valider un JWS ou JWE plusieurs fois avec différentes clés. Si l'application détermine que l'échec était dû à l'utilisation d'une clé spécifique, elle peut continuer à essayer d'autres clés jusqu'à ce qu'elle réussisse ou que toutes les clés aient été épuisées.

7.3. String Comparison Rules (Règles de comparaison de chaînes)

Le traitement d'un JWT nécessite la comparaison de valeurs de chaînes JSON.

Les comparaisons de noms de revendications et de noms de paramètres d'en-tête sont toujours effectuées comme des comparaisons de chaînes sensibles à la casse sans conversion de type.

Les comparaisons d'URI dans les valeurs StringOrURI et les valeurs de chaînes JSON sont effectuées comme suit :

• Si une valeur est un URI et l'autre n'est pas un URI, les deux valeurs sont différentes.

• Si les deux valeurs sont des URI, elles sont comparées en utilisant une comparaison de chaînes sensible à la casse sans conversion de type, canonisation ou traitement des échappements de barre oblique inverse.

• Si aucune valeur n'est un URI, elles sont comparées en utilisant une comparaison de chaînes sensible à la casse sans conversion de type ou traitement des échappements de barre oblique inverse.

Notez que pour tout cas d'utilisation donné, des règles de comparaison plus souples ou plus strictes peuvent être appropriées pour les URI et autres chaînes, mais ces règles de comparaison doivent (MUST) être explicitement spécifiées.

---