JWS vs. JWE
RFC 7515 (JWS) and RFC 7516 (JWE) were published simultaneously with JWT (RFC 7519) in May 2015 and together form the core of the JOSE (JSON Object Signing and Encryption) framework. They solve two different problems:
- JWS (JSON Web Signature): Provides integrity and authenticity. The payload is signed but not encrypted — anyone can read it, but anyone with the public key can verify it has not been tampered with. Most JWTs are JWSes.
- JWE (JSON Web Encryption): Provides confidentiality. The payload is encrypted and cannot be read without the decryption key. JWE is used when the token payload must not be readable by the bearer — for example, session tokens containing sensitive server-side state.
The two can be combined: a JWS can be used as the payload of a JWE (sign-then-encrypt), or a JWE can be signed as a JWS (encrypt-then-sign), depending on the security requirements.
Base64url in the JOSE Stack
Both JWS and JWE rely heavily on Base64url encoding (RFC 4648, Section 5). The encoding serves two purposes in the JOSE stack:
- URL safety: All components of a compact-serialised token — headers, payload, and ciphertext or signature — must be safe for use in HTTP headers and URLs. Base64url achieves this without percent-encoding overhead.
- Canonical encoding: Base64url provides a deterministic byte-to-ASCII mapping. The signature or MAC is computed over
ASCII(Base64url(header)).".".ASCII(Base64url(payload)), so any change to header or payload bytes produces a different signature input.
Compact Serialisation
Both JWS and JWE define a compact serialisation — a URL-safe string of dot-separated Base64url components:
- JWS compact:
header.payload.signature - JWE compact:
header.encrypted_key.iv.ciphertext.tag
The compact form is the one used in JWT. Both RFCs also define a JSON serialisation (representing the same token as a JSON object with named fields) intended for multi-recipient scenarios or contexts where JSON is more natural than a dot-separated string.
Where JWS and JWE Are Used Today
JWS is the signing mechanism behind virtually every JWT-based authentication system. OAuth 2.0 access tokens, OpenID Connect ID tokens, and SAML replacement tokens in modern identity systems are JWSes.
JWE sees narrower but important use:
- Server-side session state in stateless architectures (encrypted cookies)
- OpenID Connect request objects when the RP sends parameters to the OP encrypted
- Content encryption in some messaging protocols (XMPP, Matrix)
- API payloads that must be end-to-end encrypted through a proxy that cannot see the content