RFC 7519 / START HERE
JWT, before the details
JWT: JSON Web Token
A JWT carries a set of claims, such as who a token is about and when it expires, in a compact format. It can be protected with signatures or encryption.
The idea in one picture
An issuer makes claims
A token carries those claims
A recipient validates them
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
Systems sometimes need portable claims that another system can validate. Reading a token is not the same as trusting its contents.
A familiar example
An API receives a signed token and checks its signature, intended recipient, and expiry before using its claims.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- A compact token comes apartA JWT carries a JSON claims set inside a JWS or JWE representation.→
- Claims live on a timelineExpiration and not-before define a token’s permitted time interval when these claims are present.→
- Who said it, and who is it for?Issuer, subject, and audience describe different roles in a claim.→
- Signing is not hidingIntegrity and confidentiality solve different problems; nesting can combine them.→
- Validation is a chain of checksA token becomes usable only after parsing, cryptographic verification, and application checks succeed.→
- Trust comes from outside the tokenA self-described issuer or key is not enough to establish that a claim should be believed.→
This introduction explains RFC 7519 (2015). Read the original RFC ↗