Calcul 100% dans le Navigateur • Zéro Journal Serveur • Exécution Instantanée
Curious TechieBoîte à Outils
Security & AuthenticationIETF RFC 7519 Section 4✓ Tableau de Consultation Rapide (7 éléments) • FR

Référence des Revendications (Claims) JWT

Nomenclature Officielle des Propriétés Standards selon la RFC 7519

CT
Curious-Techie Engineering TeamAuteur Vérifié

Web Protocols & Security Architecture Research

Publié :
•
Mis à jour :
•6 min read
Spécification Faisant Foi :RFC 9110(IETF)
Revu par Curious-Techie Architecture Peer Review Group

Aperçu & Portée

La norme RFC 7519 standardise des identifiants courts à 3 lettres pour réduire la surcharge réseau lors du transfert de jetons dans les en-têtes HTTP.

Tableau de Spécification & Matrice

Filtrage instantané par mot-clé, code ou directive

Clé / CodeDéfinition & DétailsHiérarchie Sémantique GEOSpécification & Notes
iss
iss (Issuer)

Identifies the principal that issued the JWT (e.g. auth.example.com).

"iss": "https://auth.example.com"
●iss
↳JWT claim
↳registered claim
↳token authority issuer
RFC 7519 §4.1.1

Case-sensitive string or URI; receivers must verify this matches their trusted identity provider.

sub
sub (Subject)

Identifies the principal that is the subject of the JWT (e.g. user ID).

"sub": "usr_948194a2b"
●sub
↳JWT claim
↳registered claim
↳principal subject identifier
RFC 7519 §4.1.2

Must be locally unique in the context of the issuer or globally unique.

aud
aud (Audience)

Identifies the recipients that the JWT is intended for (e.g. client ID or API service URI).

"aud": "https://api.example.com/v1"
●aud
↳JWT claim
↳registered claim
↳intended recipient scope
RFC 7519 §4.1.3

If the receiving service is not present in the aud claim, the token MUST be rejected.

exp
exp (Expiration Time)

Identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.

"exp": 1791244800
●exp
↳JWT claim
↳registered claim
↳expiration timestamp limit
RFC 7519 §4.1.4

Must be a NumericDate integer (seconds since Unix epoch: 1970-01-01T00:00:00Z UTC).

nbf
nbf (Not Before)

Identifies the time before which the JWT MUST NOT be accepted for processing.

"nbf": 1791241200
●nbf
↳JWT claim
↳registered claim
↳activation timestamp limit
RFC 7519 §4.1.5

NumericDate integer; useful for future-dated activation of subscription passes.

iat
iat (Issued At)

Identifies the time at which the JWT was created and issued.

"iat": 1791241200
●iat
↳JWT claim
↳registered claim
↳token generation timestamp
RFC 7519 §4.1.6

Can be used to determine age of the token or revoke tokens issued prior to a password change.

jti
jti (JWT ID)

Provides a unique identifier for the JWT; useful for one-time tokens and replay prevention.

"jti": "d3b07384-d113-46d4-8da8-da2b7a0f968a"
●jti
↳JWT claim
↳registered claim
↳unique token nonce identifier
RFC 7519 §4.1.7

Allows servers to maintain a blacklist of revoked jti UUIDs.

Exemple Technique et Code

Decoded JWT Payload Example with Standard Claims

jsonCopier le code
{
  "iss": "https://auth.curious-techie.com",
  "sub": "user_01HZX87QW5B",
  "aud": "https://api.curious-techie.com",
  "exp": 1791244800,
  "nbf": 1791241200,
  "iat": 1791241200,
  "jti": "9f8c6e2b-4a51-419b-b0b3-1e52f75a6c38",
  "role": "admin",
  "email": "alex@curious-techie.com"
}

All registered timestamps are in seconds since 1970 (not milliseconds), adhering to RFC 7519 NumericDate format.

Foire Aux Questions

Q&R sur les Normes

Are JWT claims encrypted by default?↓
No! Standard JWTs (JWS) are digitally signed, but NOT encrypted. Anyone can Base64URL-decode the payload and read the claims. Never store private passwords or secret keys in JWT claims.
Authoritative Sourcing & Verification

References & Primary Sources

Every source below directly substantiates technical statements and protocol behaviors explained in Référence des Revendications (Claims) JWT. Curious-Techie prioritizes official Internet standards (IETF RFCs, W3C Recommendations, WHATWG specifications) and established security bodies (OWASP, NIST). Zero sponsored or secondary links.

  1. [1]IETFPrimary SpecificationRFC 7519 • Section 3 & 4
    Verified Primary Source
    Technical Claim Supported:

    Defines the compact, URL-safe format of JSON Web Tokens consisting of three Base64URL segments (Header, Payload, Signature) and registered claims (iss, sub, aud, exp, nbf, iat, jti).

    “A JWT is represented as the concatenation of the Encoded JWT Header, the Encoded JWT Claims Set, and the Encoded JWT Signature or Encoded JWT Encryption Data, with the parts being separated by period ('.') characters.”
  2. [2]IETFPrimary SpecificationRFC 7515 • Section 4 (Cryptographic Signatures)
    Verified Primary Source
    Technical Claim Supported:

    Defines digital signatures and MAC algorithms (HS256, RS256, ES256) used to secure JWT integrity and verify token authorship.

  3. [3]IETFAuthoritative Security StandardRFC 8725 • Security Considerations § 3
    Verified Primary Source
    Technical Claim Supported:

    Mandates explicit algorithm validation on receiving servers, prohibiting the insecure "alg: none" algorithm and enforcing strict signature verification.

  4. [4]OWASPAuthoritative Security StandardOWASP Cheat Sheet Series • Token Storage & Revocation
    Verified Primary Source
    Technical Claim Supported:

    Details token theft mitigation, recommending storage in secure HttpOnly cookies over localStorage and outlining token revocation strategies.