Claim (JWT)

Un claim est une paire nom/valeur dans une charge utile JWT qui affirme quelque chose sur le sujet du jeton. Les claims sont des propriétés JSON ; la charge utile est un objet JSON les contenant. Claims standard définis dans la RFC 7519 §4 :

• iss — Émetteur (Issuer) : qui a créé le jeton.
• sub — Sujet (Subject) : à qui le jeton se rapporte (typiquement un ID utilisateur).
• aud — Audience : à qui le jeton est destiné. Peut être une chaîne ou un tableau.
• exp — Expiration : secondes Unix après lesquelles le jeton doit être rejeté.
• iat — Émis à (Issued At) : secondes Unix quand le jeton a été créé.
• nbf — Pas avant (Not Before) : secondes Unix avant lesquelles le jeton est invalide.
• jti — ID JWT : un identifiant unique pour le suivi de révocation.

Au-delà de l’ensemble standard, les applications ajoutent leurs propres claims : role, email, tenant_id, permissions, etc. La RFC 7519 ne restreint pas à quoi ressemblent les claims personnalisés, bien que l’IANA maintienne un registre de noms bien connus pour éviter les collisions.

Trois classes de claims méritent d’être distinguées : enregistrés (les sept ci-dessus, gérés par l’IANA), publics (enregistrés auprès de l’IANA ou avec un espace de noms sous un URI pour éviter les conflits) et privés (mutuellement convenus entre émetteur et consommateur ; pas d’espace de noms).

Décodez et inspectez chaque claim dans un JWT avec notre décodeur JWT. Il affiche les claims standard séparément et montre le temps restant avant expiration par rapport à l’heure actuelle de votre machine.

Espace de noms des claims personnalisés — la pratique standard : lorsqu’une application ajoute des claims personnalisés qui peuvent ensuite être intégrés dans un jeton partagé entre fournisseurs, préfixez-les avec un URI que vous possédez. Auth0 utilise https://votredomaine.com/claims/role ; AWS Cognito utilise cognito:groups. Les noms nus comme role ou permissions sont pratiques mais risquent de rentrer en collision avec de futurs claims enregistrés par l’IANA et avec les conventions d’autres fournisseurs. OpenID Connect spécifie certains noms conventionnels (email, name, given_name, family_name, picture, locale) qui ont des significations stables entre les fournisseurs d’identité — ceux-ci sont sûrs à utiliser tels quels dans tout flux conforme OIDC. Référence : Registre IANA des claims JSON Web Token.

Exemple : valider exp et nbf

Considérez une charge utile JWT {"sub":"42","iat":1716220800,"exp":1716224400,"nbf":1716220800}. Le jeton a été émis au timestamp Unix 1716220800 (2024-05-20 16:00:00 UTC), est valide immédiatement et expire à 1716224400 (2024-05-20 17:00:00 UTC) — une durée de vie d’une heure. Un vérificateur correct lit l’heure Unix actuelle, rejette le jeton si maintenant ≥ exp (avec une petite tolérance optionnelle, typiquement 30 à 60 secondes, pour absorber le décalage d’horloge entre services) et rejette si maintenant < nbf. La RFC 7519 §4.1.4 exige que le traitement de exp “DOIT” tenir compte du décalage d’horloge mais laisse la tolérance à l’implémenteur. Une tolérance de 60 secondes est la norme industrielle de facto ; jose, jsonwebtoken et pyjwt utilisent tous des fenêtres configurables de 0 à 60 s.

Pourquoi c’est important : les implications de sécurité

La plupart des incidents de sécurité JWT sont liés à des omissions de validation de claims, pas à des défaillances cryptographiques. L’avis Auth0 CVE-2018-0114 de 2018 documentait des bibliothèques qui vérifiaient la signature mais ignoraient exp, permettant la réutilisation indéfinie de jetons volés. Plusieurs frameworks ont livré des vérificateurs par défaut qui ignorent aud, permettant à un jeton émis pour un service d’être accepté par un autre dans le même domaine de confiance. Bonne pratique : vérifiez toujours l’ensemble complet des claims standard applicables (iss, aud, exp, nbf, plus la signature et la liste d’autorisation d’algorithmes) — chaque bibliothèque expose ces options comme paramètres de constructeur ou d’appel de vérification, et le coût de leur activation est essentiellement nul. Référence : RFC 8725 — Meilleures pratiques actuelles pour JSON Web Token.