In May 2015, the Internet Engineering Task Force (IETF) published RFC 7519, officially standardizing the JSON Web Token (JWT) format as an Internet Proposed Standard.
While millions of developers use JWTs daily, few have read the specification. This guide walks you through RFC 7519 in clear, plain English, demystifying the JOSE suite, claim registries, character encoding rules, and formal security recommendations.
1. The JOSE Family of Standards
RFC 7519 does not exist in isolation. It is part of the JOSE (Javascript Object Signing and Encryption) suite of RFCs:
📜 The IETF JOSE Standard Ecosystem
RFC Architecture- RFC 7515 (JWS): JSON Web Signature: Standardizes how JSON data is cryptographically signed and serialized.
- RFC 7516 (JWE): JSON Web Encryption: Standardizes how JSON data is encrypted for confidentiality.
- RFC 7517 (JWK): JSON Web Key: Standardizes how cryptographic keys are represented as JSON structures.
- RFC 7518 (JWA): JSON Web Algorithms: Enumerates cryptographic algorithms (HMAC, RSA, ECDSA, AES-GCM).
- RFC 7519 (JWT): JSON Web Token: Standardizes representing claims as a JSON object that is signed using JWS or encrypted using JWE.
2. Key Terminology Defined by RFC 7519
- Claim: A piece of asserted information about a subject represented as a name/value pair (e.g.,
"sub": "user_42"). - JWT Claims Set: A JSON object containing one or more claims.
- JOSE Header: JSON object containing parameters that describe the cryptographic operations applied to the token.
- Unsecured JWT: A JWT whose claims are not cryptographically signed or encrypted (using
"alg": "none"). - NumericDate: A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified date/time, ignoring leap seconds.
3. The Three Categories of Claims
RFC 7519 organizes claim names into three distinct categories to avoid collision across different applications:
| Category | Registry / Governance | Purpose & Rules |
|---|---|---|
| Registered Claims | IANA "JSON Web Token Claims" Registry | Predefined standard claims (iss, sub, aud, exp, nbf, iat, jti) meant to be universally understood. |
| Public Claims | IANA or Collision-Resistant Namespaces | Claims defined by external specifications or organizations. Must use a collision-resistant name, such as a URI (e.g. "https://example.com/jwt_claims/role"). |
| Private Claims | Agreed-upon between producer and consumer | Custom application claims (e.g. "tenant_id", "tier"). Subject to collisions if shared between multiple unrelated systems. |
4. Base64URL Encoding Rules (RFC 7515 Section 2)
RFC 7519 mandates Base64URL encoding without padding:
- The characters
+and/from standard Base64 are replaced with-(minus) and_(underscore) so the token can safely appear in URLs, HTTP headers, and query strings without percent-encoding. - All trailing
=padding characters MUST be omitted.
5. Integrity vs. Confidentiality
One of the most important takeaways from RFC 7519 is understanding the difference between signing and encrypting:
⚠️ JWS Signs; JWE Encrypts
Standard JSON Web Tokens are JWS (JSON Web Signature) objects. JWS guarantees integrity (the data has not been altered) and authenticity (the token was created by the key holder). It does NOT provide confidentiality. Anyone can decode and inspect the payload!
If you must pass sensitive claims (such as HIPAA healthcare identifiers or proprietary data) across untrusted channels, you must wrap your token using JWE (RFC 7516).
6. Official Security Considerations (RFC 7519 Section 11)
The IETF authors dedicated Section 11 to security recommendations:
- Trust Boundaries: The recipient MUST NOT rely on any claim in the JWT until the digital signature has been successfully verified.
- Cryptographic Agility: Systems must validate that the algorithm in the header matches expected algorithms for the current key.
- Replay Prevention: If a token can be replayed maliciously, implement a unique
jti(JWT ID) claim and track processed tokens until theirexptimestamp.