RFC 7515 / START HERE
JWS, before the details
JWS: JSON Web Signature
JWS represents content protected with a digital signature or a message authentication code. It describes how the protected content and its integrity information are packaged.
The idea in one picture
A producer protects content
JWS carries content and proof
A recipient verifies integrity
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
A recipient may need to detect tampering and verify who could have produced a message. Signing does not hide the message content.
A familiar example
A service signs a token; another service verifies its integrity before accepting its contents.
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.
- What the signature coversIn the default compact form, signing covers the encoded protected header, a dot, and the encoded payload.→
- Verification is a gateA consumer verifies the signature or MAC before treating the protected content as authenticated.→
- Protected and unprotected headersJWS JSON serialization can carry header values outside the signature’s protection.→
- One payload, several signaturesThe general JSON serialization can associate several signatures with one payload.→
- Authenticity does not stop replayA valid signed message can be copied and submitted again.→
This introduction explains RFC 7515 (2015). Read the original RFC ↗