RFC 8725 / START HERE
JWT security, before the details
JWT security best practices
JWT means JSON Web Token. This RFC explains checks and design choices needed to use JWTs safely rather than trusting a token merely because it can be decoded.
The idea in one picture
A service receives a token
It checks integrity and context
Only suitable claims are accepted
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
Weak algorithm choices and confused token contexts can turn a valid-looking token into a security problem.
A familiar example
An API restricts accepted algorithms and checks the token's issuer, audience, and purpose 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.
- Do not let alg choose the policyThe receiving application limits acceptable algorithms instead of trusting the token header to decide.→
- A password is a weak MAC keyHMAC keys need enough entropy; a human-memorable password is not an appropriate substitute.→
- Nested tokens need every checkAn outer encrypted token does not excuse skipping the inner signature verification.→
- Bind issuer and audienceA valid signature must be tied to the expected issuer and intended recipient.→
- Different purposes need different rulesToken kinds sharing an ecosystem must not be interchangeable.→
This introduction explains RFC 8725 (2020). Read the original RFC ↗