4. JWT Claims (Revendications JWT)
Le JWT Claims Set (Ensemble de revendications JWT) représente un objet JSON dont les membres sont les revendications transmises par le JWT. Les Claim Names (Noms de revendications) dans un JWT Claims Set doivent être uniques (MUST). Les parseurs JWT doivent soit rejeter les JWT avec des noms de revendications dupliqués (MUST), soit utiliser un parseur JSON qui ne retourne que le dernier nom de membre dupliqué lexicalement, comme spécifié dans la section 15.12 ("The JSON Object") d'ECMAScript 5.1 [ECMAScript].
L'ensemble de revendications qu'un JWT doit contenir pour être considéré comme valide dépend du contexte et est en dehors du champ d'application de cette spécification. Les applications spécifiques des JWT exigeront que les implémentations comprennent et traitent certaines revendications de manières particulières. Cependant, en l'absence de telles exigences, toutes les revendications qui ne sont pas comprises par les implémentations doivent être ignorées (MUST).
Il existe trois classes de JWT Claim Names : Registered Claim Names (Noms de revendications enregistrés), Public Claim Names (Noms de revendications publics) et Private Claim Names (Noms de revendications privés).
4.1. Registered Claim Names (Noms de revendications enregistrés)
Les noms de revendications suivants sont enregistrés dans le registre IANA "JSON Web Token Claims" établi par la section 10.1. Aucune des revendications définies ci-dessous n'est destinée à être obligatoire à utiliser ou à implémenter dans tous les cas, mais elles fournissent plutôt un point de départ pour un ensemble de revendications utiles et interopérables. Les applications utilisant des JWT devraient spécifier (SHOULD) quelles revendications spécifiques elles utilisent et quand elles sont requises ou optionnelles. Tous les noms sont courts car un objectif fondamental des JWT est que la représentation soit compacte.
4.1.1. "iss" (Issuer) Claim (Revendication d'émetteur)
La revendication "iss" (issuer) identifie le principal qui a émis le JWT. Le traitement de cette revendication est généralement spécifique à l'application. La valeur "iss" est une chaîne sensible à la casse contenant une valeur StringOrURI. L'utilisation de cette revendication est optionnelle (OPTIONAL).
4.1.2. "sub" (Subject) Claim (Revendication de sujet)
La revendication "sub" (subject) identifie le principal qui est le sujet du JWT. Les revendications dans un JWT sont normalement des déclarations concernant le sujet. La valeur du sujet doit (MUST) être soit limitée pour être localement unique dans le contexte de l'émetteur, soit être globalement unique. Le traitement de cette revendication est généralement spécifique à l'application. La valeur "sub" est une chaîne sensible à la casse contenant une valeur StringOrURI. L'utilisation de cette revendication est optionnelle (OPTIONAL).
4.1.3. "aud" (Audience) Claim (Revendication d'audience)
La revendication "aud" (audience) identifie les destinataires auxquels le JWT est destiné. Chaque principal destiné à traiter le JWT doit s'identifier (MUST) avec une valeur dans la revendication d'audience. Si le principal traitant la revendication ne s'identifie pas avec une valeur dans la revendication "aud" lorsque cette revendication est présente, alors le JWT doit être rejeté (MUST). Dans le cas général, la valeur "aud" est un tableau de chaînes sensibles à la casse, chacune contenant une valeur StringOrURI. Dans le cas spécial où le JWT n'a qu'une seule audience, la valeur "aud" peut (MAY) être une seule chaîne sensible à la casse contenant une valeur StringOrURI. L'interprétation des valeurs d'audience est généralement spécifique à l'application. L'utilisation de cette revendication est optionnelle (OPTIONAL).
4.1.4. "exp" (Expiration Time) Claim (Revendication de temps d'expiration)
La revendication "exp" (expiration time) identifie le temps d'expiration à partir duquel ou après lequel le JWT ne doit pas être accepté (MUST NOT) pour traitement. Le traitement de la revendication "exp" exige que la date/heure actuelle soit (MUST) avant la date/heure d'expiration listée dans la revendication "exp". Les implémenteurs peuvent (MAY) prévoir une petite marge, généralement pas plus de quelques minutes, pour tenir compte du décalage d'horloge. Sa valeur doit (MUST) être un nombre contenant une valeur NumericDate. L'utilisation de cette revendication est optionnelle (OPTIONAL).
4.1.5. "nbf" (Not Before) Claim (Revendication de temps de début)
La revendication "nbf" (not before) identifie le temps avant lequel le JWT ne doit pas être accepté (MUST NOT) pour traitement. Le traitement de la revendication "nbf" exige que la date/heure actuelle soit (MUST) après ou égale à la date/heure de début listée dans la revendication "nbf". Les implémenteurs peuvent (MAY) prévoir une petite marge, généralement pas plus de quelques minutes, pour tenir compte du décalage d'horloge. Sa valeur doit (MUST) être un nombre contenant une valeur NumericDate. L'utilisation de cette revendication est optionnelle (OPTIONAL).
4.1.6. "iat" (Issued At) Claim (Revendication de temps d'émission)
La revendication "iat" (issued at) identifie le moment auquel le JWT a été émis. Cette revendication peut être utilisée pour déterminer l'âge du JWT. Sa valeur doit (MUST) être un nombre contenant une valeur NumericDate. L'utilisation de cette revendication est optionnelle (OPTIONAL).
4.1.7. "jti" (JWT ID) Claim (Revendication d'ID JWT)
La revendication "jti" (JWT ID) fournit un identifiant unique pour le JWT. La valeur de l'identifiant doit (MUST) être attribuée de manière à garantir qu'il y a une probabilité négligeable que la même valeur soit accidentellement attribuée à un objet de données différent ; si l'application utilise plusieurs émetteurs, les collisions doivent (MUST) également être empêchées parmi les valeurs produites par différents émetteurs. La revendication "jti" peut être utilisée pour empêcher la relecture du JWT. La valeur "jti" est une chaîne sensible à la casse. L'utilisation de cette revendication est optionnelle (OPTIONAL).
4.2. Public Claim Names (Noms de revendications publics)
Les noms de revendications peuvent être définis à volonté par ceux qui utilisent des JWT. Cependant, afin de prévenir les collisions, tout nouveau nom de revendication devrait (SHOULD) soit être enregistré dans le registre IANA "JSON Web Token Claims" établi par la section 10.1, soit être un nom public (Public Name) : une valeur qui contient un nom résistant aux collisions (Collision-Resistant Name). Dans chaque cas, le définisseur du nom ou de la valeur doit prendre des précautions raisonnables pour s'assurer qu'il contrôle la partie de l'espace de noms qu'il utilise pour définir le nom de revendication.
4.3. Private Claim Names (Noms de revendications privés)
Un producteur et un consommateur d'un JWT peuvent (MAY) convenir d'utiliser des noms privés (Private Names) comme noms de revendications : des noms qui ne sont ni des noms de revendications enregistrés (Section 4.1) ni des noms de revendications publics (Section 4.2). Contrairement aux noms de revendications publics, les noms de revendications privés sont sujets à collision et doivent être utilisés avec prudence.