| Revendication | Description |
|---|---|
iss | Identifies the principal that issued the JWT. Typically the auth server URL. |
sub | Identifies the principal that is the subject of the JWT — usually the user ID. |
aud | Identifies the recipients that the JWT is intended for. The API must check this. |
exp | The time after which the JWT MUST NOT be accepted. Critical for security. |
nbf | The time before which the JWT MUST NOT be accepted. Useful for deferred activation. |
iat | The time at which the JWT was issued. Used to determine the age of the token. |
jti | Unique identifier for the JWT. Prevents token replay attacks when combined with a blocklist. |
| Revendication | Description |
|---|---|
name | End-user's full name in displayable form. |
given_name | Given name(s) or first name of the end-user. |
family_name | Surname(s) or last name of the end-user. |
email | End-user's preferred email address. |
email_verified | True if the end-user's email has been verified by the Provider. |
picture | URL of the end-user's profile picture. |
locale | End-user's locale as a BCP 47 language tag. |
zoneinfo | End-user's time zone from the IANA Time Zone Database. |
updated_at | Time the end-user's information was last updated. |
nonce | String value used to associate a Client session with an ID Token and to mitigate replay attacks. |
at_hash | Hash of the Access Token value. Used to validate the access_token. |
auth_time | Time when the end-user was authenticated. |
| Revendication | Description |
|---|---|
scope | OAuth 2.0 scopes granted to the token. Defines what resources the token can access. |
roles | Non-standard but widely used. Application roles assigned to the user. |
permissions | Fine-grained permissions. Used by Auth0, AWS Cognito, and others. |
azp | The client_id of the OAuth 2.0 Client that requested the token. Used with OIDC. |
acr | Level of authentication that occurred. Values defined by the deployment. |
amr | How the user was authenticated (password, OTP, biometric, etc.). |
| Revendication | Description |
|---|---|
tenant_id | Multi-tenant app custom claim. Identifies the tenant/organization. |
org_id | Organization identifier used by Auth0, WorkOS, and similar platforms. |
plan | User's subscription tier. Common in SaaS billing-based access control. |
| Revendication | Description |
|---|---|
Verify exp | Reject any token where exp < current time (in UTC seconds). Add small clock skew (30–60s). |
Verify iss | Must exactly match the expected issuer URL. Reject mismatches. |
Verify aud | Must contain your API's identifier. Reject tokens issued for other audiences. |
Verify signature | NEVER trust a JWT without verifying its cryptographic signature using the correct key/JWKS. |
Check nbf | If nbf is present, reject tokens used before this time. |
Check alg | Explicitly specify expected algorithm. Reject 'none' algorithm. Prefer RS256 or ES256 over HS256 for public APIs. |
| Revendication | Description |
|---|---|
HS256 | Fast; uses a single shared secret for sign & verify. Only suitable when both parties are trusted (e.g., server-to-server). |
HS512 | Like HS256 but with 512-bit hash output. Marginally stronger for symmetric use cases. |
RS256 | Most widely supported asymmetric algorithm. Sign with private key, verify with public key. Use this for public APIs and OIDC. |
RS512 | RS256 with SHA-512. Stronger hash but same RSA security level. Marginally slower. |
ES256 | Compact, fast asymmetric algorithm. Smaller keys than RSA for equivalent security. Recommended for new systems. |
PS256 | More secure padding than RS256 (probabilistic). Required by FAPI (Financial-grade API) and advanced OIDC profiles. |
EdDSA | Modern elliptic curve algorithm. Fastest, smallest signatures. Use with jose library. Not universally supported yet. |
Un JWT est composé de trois parties encodées en Base64URL séparées par des points : En-tête.Charge utile.Signature
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJ1c2VyXzEyMyIsImF1ZCI6Imh0dHBzOi8vYXBpLmV4YW1wbGUuY29tIiwiZXhwIjoxNzM1Njg5NjAwLCJpYXQiOjE3MzU2MDMyMDAsInNjb3BlIjoicmVhZDp1c2VycyJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
{"alg":"RS256","typ":"JWT"}Algorithme et type de jeton
{"iss":"https://auth.example.com","sub":"user_123","exp":1735689600,...}Revendications — les données
RSASHA256(base64url(header) + '.' + base64url(payload), privateKey)Vérification cryptographique
exp (expiration time) est le moment où le token expire et ne doit plus être accepté après ce moment. nbf (not before) est le moment où le token devient valide — il ne doit pas être accepté avant ce moment. iat (issued at) enregistre quand le token a été émis — utile pour déterminer l'âge du token. Les trois utilisent le format NumericDate (secondes depuis l'epoch Unix).
Les access tokens doivent être de courte durée : 5-60 minutes pour la plupart des apps, 1-24 heures pour les APIs. Les refresh tokens peuvent être plus longs : jours à semaines. Une courte expiration limite les dommages en cas de vol de token. Ne stockez jamais de données sensibles dans les payloads JWT car ils sont encodés en base64url (pas chiffrés) et peuvent être décodés par n'importe qui.
sub (subject) identifie le principal (généralement un ID utilisateur) auquel le JWT fait référence. Il doit être unique dans le contexte de l'émetteur. Utilisez un identifiant stable et non réattribuable (comme un UUID ou un ID numérique) plutôt qu'un nom d'utilisateur ou un email, qui peut changer.
Oui, pour l'autorisation sans état. Incluez les rôles/permissions dans des claims personnalisés (ex. 'roles': ['admin', 'user']). Cependant, gardez les tokens légers — n'incluez pas tout. Pour des permissions fines, envisagez un modèle de token de référence où le JWT contient un ID de session et vous recherchez les permissions côté serveur.