Générateur de Payload & Constructeur de Claims JWT (Norme RFC 7519) Guide Développeur

Générateur de Payload & Constructeur de Claims JWT (Norme RFC 7519) Guide Développeur

Concevez des claims JWT enregistrés et personnalisés conformes au RFC 7519 avec calculatrices d'horodatage pour exp, nbf, iat, jti et audience.

Presets label
Registered claims
7 / 7 configured
StringOrURI
Principal ID
Target APIs / Clients
https://api.toolsaa.com/v1https://billing.toolsaa.com
In 1h
Quick Lifespan:
Custom claims
Templates:
{
  "iss": "https://auth.toolsaa.com",
  "sub": "usr_89f72b10",
  "aud": [
    "https://api.toolsaa.com/v1",
    "https://billing.toolsaa.com"
  ],
  "exp": 1792178372,
  "nbf": 1792174772,
  "iat": 1792174772,
  "jti": "f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
  "scope": "read:profile write:workspace admin:billing",
  "client_id": "spa_client_prod_442"
}
Stat status
7 / 7 Claims

Standard iss, sub, aud, exp, nbf, iat, jti validation

Stat lifespan
In 1h

Second-level Unix epoch precision

Stat payload size
305 Bytes

~3.7% of 8KB HTTP header buffer

Client-Side Processing

High-performance processing executed entirely in browser memory.

Zero Server Upload Privacy

All data payloads remain strictly local with zero external server communication.

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

Référence technique et guide d'architecture

Générateur de Payload & Constructeur de Claims JWT (Norme RFC 7519) Guide Développeur — Guide de référence

Concevez des claims JWT enregistrés et personnalisés conformes au RFC 7519 avec calculatrices d'horodatage pour exp, nbf, iat, jti et audience.

Paramètres clés et contrôles

iss (Issuer / Émetteur)string

Identifie l'émetteur du JWT (généralement l'URI du service d'authentification ou du fournisseur d'identité).

Par défaut : https://auth.example.com
sub (Subject / Sujet)string

Identifie l'entité visée par le jeton (UUID utilisateur ou identifiant de compte de service).

Par défaut : usr_94b3a8c1-5e2b
aud (Audience)string | string[]

Identifie les destinataires prévus du token. Le serveur de ressources doit impérativement vérifier que son identifiant figure dans ce claim.

Par défaut : https://api.example.com/v1
exp (Expiration Time / Expiration)integer (timestamp Unix en secondes)

Date et heure après lesquelles le jeton ne doit plus être accepté (NumericDate RFC 7519 en secondes).

Par défaut : 1776435600
jti (JWT ID / Identifiant Unique)string

Identifiant unique du jeton permettant de neutraliser les attaques par rejeu et de gérer les listes de révocation.

Par défaut : b9c8d6e4-4a2f-48d1-912b-3e5f7a1c8d9e

Conseils de pro et bonnes practices

Utiliser des secondes Unix et non des millisecondes

La norme RFC 7519 impose NumericDate en secondes depuis l'époque Unix. Passer 'Date.now()' de JavaScript sans diviser par 1000 produit une date située dans 50 000 ans ou un rejet immédiat par les bibliothèques de validation.

Limiter la taille du Payload pour préserver les en-têtes HTTP

Les JWT transitent à chaque requête dans l'en-tête Authorization. Évitez les matrices de permissions volumineuses ou les profils complets pour ne pas dépasser la limite de 8 Ko fixée par Nginx et Cloudflare.

Définir une tolérance de décalage d'horloge (Clock Skew)

Dans les architectures distribuées, de légers écarts NTP existent entre serveurs. Configurez toujours une tolérance de 30 à 60 secondes (clockTolerance / leeway) dans votre middleware de vérification pour éviter les rejets inopportuns.

Pièges courants et dépannage

Le token est immédiatement rejeté avec l'erreur 'TokenExpiredError'

Vérifiez si le claim 'exp' a été encodé en millisecondes. Assurez-vous d'utiliser 'Math.floor(Date.now() / 1000) + ttl' et accordez 60 secondes de tolérance horlogère sur le validateur.

La signature est valide mais l'API renvoie 'jwt audience invalid' (401/403)

Le serveur de ressources exige que son identifiant ou URI corresponde exactement au claim 'aud'. Ajustez la valeur ou définissez un tableau d'audiences si plusieurs services exploitent le même token.

Foire aux questions (FAQ)

Quelle est la différence entre les claims Enregistrés, Publics et Privés dans la RFC 7519 ?▼

Les claims enregistrés (iss, sub, aud, exp, nbf, iat, jti) sont standardisés par l'IANA pour garantir la sécurité. Les claims publics sont déclarés auprès de l'IANA ou définis par des URI uniques. Les claims privés sont des données spécifiques convenues entre l'émetteur et le récepteur (ex. : role, tenant_id).

Pourquoi la RFC 7519 utilise-t-elle des secondes et non des millisecondes pour les horodatages ?▼

Pour respecter la norme temporelle POSIX et limiter le nombre d'octets transférés dans les en-têtes HTTP des requêtes web.

Peut-on stocker des mots de passe ou des données confidentielles dans un JWT classique ?▼

Non. Un jeton standard signé (JWS) est simplement encodé en Base64URL et n'est pas chiffré : tout le monde peut en lire le contenu. Pour protéger des données sensibles, vous devez employer le chiffrement JWE (RFC 7516).

Comment le claim 'jti' prévient-il les attaques par rejeu ?▼

En affectant un UUID unique à chaque jeton, le serveur de ressources peut inscrire le 'jti' utilisé dans un cache ultra-rapide (comme Redis) jusqu'à l'expiration du token. Toute tentative ultérieure de réutilisation du même 'jti' est alors instantanément bloquée.

Outils et utilitaires connexes

Tous les outils →