skip to content

In JOSE, what is the difference between a JWS and a JWE, and who can read each payload?

level: juniorimportance: must knowfreq 75%

answer

  1. Encoding is not encryption
  2. Integrity versus confidentiality
  3. Ask what a proxy or log sees
  4. Three dot-separated parts versus five

basics

~20 s

A JWS is signed but not encrypted: anyone holding it can decode and read the claims, and the signature only proves they were not altered. A JWE encrypts the payload, so only a holder of the decryption key can read it.

solid answer

~40 s

JOSE defines two container shapes. A **JWS** (RFC 7515) carries a Base64url-encoded header and payload plus a signature or MAC over them; the payload is *encoded*, not encrypted, so any party that holds the token — a browser, a proxy, a log aggregator — can decode it and read every claim. What the signature buys is integrity and, with an asymmetric algorithm, proof of who issued it. A **JWE** (RFC 7516) instead encrypts the claims: the compact form has five parts (protected header, encrypted key, IV, ciphertext, authentication tag) rather than three, and only a party holding the right decryption key sees the claims. The practical rule: a plain signed JWT is a postcard with a tamper-evident seal, so it must never carry data you would not print on that postcard.

code

text · 5 lines
text
JWS compact (3 parts):
  BASE64URL(protected header) . BASE64URL(payload) . BASE64URL(signature)

JWE compact (5 parts):
  BASE64URL(protected header) . BASE64URL(encrypted key) . BASE64URL(iv) . BASE64URL(ciphertext) . BASE64URL(tag)

go deeper

for a junior

Be ready to say plainly that a signed JWT's payload is readable by anyone holding the token, and that Base64url is encoding rather than encryption.

for a middle

Explain the mechanics: three compact segments for a JWS versus five for a JWE, and which security property each container actually provides.

for a senior

Show you reason about where tokens rest — logs, browser storage, proxies — and can justify why a given claim does or does not belong in a signed-only token.

for a principal

Own the tradeoff: a JWE buys confidentiality at the cost of per-audience key distribution and lost debuggability, so argue when that cost is worth paying versus keeping data server-side.

## The family the terms come from JOSE — JSON Object Signing and Encryption — is a set of RFCs that together define how to protect a JSON payload. The two container formats are **JWS**, JSON Web Signature (RFC 7515), and **JWE**, JSON Web Encryption (RFC 7516). Supporting specs define the key format (JWK, RFC 7517) and the algorithm identifiers (JWA, RFC 7518). A **JWT** (RFC 7519) is not a third format: it is a set of claims — a JSON object — carried *inside* either a JWS or a JWE. So "is a JWT encrypted?" is really the question "is this JWT a JWS or a JWE?", and in the overwhelming majority of real systems the answer is JWS. ## What a JWS looks like and what it guarantees A JWS in compact serialization is three Base64url segments separated by dots: the protected header, the payload, and the signature. Base64url is an *encoding* — a reversible mapping of bytes to URL-safe characters with no key involved. Pasting a JWS into any decoder prints the claims in clear JSON. The signature is a separate value computed over the first two segments; it lets a verifier detect that a single character was changed, and, when the algorithm is asymmetric, that the holder of a particular private key produced it. The security properties, stated precisely: **integrity** (the claims were not modified after issuance) and **authenticity of origin** (someone holding the signing key issued them). Nothing about **confidentiality**. A JWS does not hide the subject identifier, the tenant, the role list, the email address, or anything else you placed in the claims. ## What a JWE looks like and what it adds A JWE in compact serialization is five Base64url segments: protected header, encrypted key, initialization vector, ciphertext, and authentication tag. The claims live in the ciphertext segment. The header stays readable — it has to, because the recipient needs it to know how to decrypt — and it is integrity-protected as additional authenticated data rather than hidden. So a JWE gives **confidentiality of the claims** plus integrity of the ciphertext. One subtlety that separates strong candidates: a JWE by itself does not prove *who* created it. If the content key is delivered under the recipient's public key, anybody who can fetch that public key can produce a well-formed JWE for that recipient. Origin authentication comes from a signature, which is why systems that need both nest a JWS inside a JWE. ## Where the difference bites in production Bearer tokens end up in more places than the request path: browser storage, mobile keychains and crash reports, reverse-proxy access logs, APM traces, support tickets pasted by users, and error payloads. TLS protects the token while it is on the wire and nothing after that. Every one of those resting places can read a JWS payload. That is why "put the customer's identifier and their role in the token, but never their diagnosis, their salary, or an internal secret" is the standard discipline. Size and operability push the other way. A JWE is longer, cannot be inspected during an incident without a key, and requires the issuer to hold a public key for every audience that must decrypt — a key-distribution job in the opposite direction from signature verification. Signature verification keys can be published to the world; decryption keys cannot. ## Choosing between them Use a JWS when the parties that will hold the token are allowed to read its claims — which covers most first-party access tokens and ID tokens. Use a JWE when the token passes through a party that must relay it but must not read it, or when a regulatory constraint forbids the claims from resting in clear form outside the issuer and the intended recipient. Use a nested JWT — sign, then encrypt — when you need both origin proof and confidentiality. ## What neither of them gives you Both are bearer credentials. Whoever holds the bytes can present them. Encryption does not stop replay, signing does not stop theft, and neither one revokes a token that has already been issued. That is why short lifetimes and sender-constraining mechanisms exist alongside the format, not inside it.

  • If a JWE hides the claims, does it also prove who issued the token?
    Not on its own. When the content key is wrapped under the recipient's public key, anyone who can obtain that public key can produce a valid JWE for that recipient. Confidentiality and origin authentication are separate properties, which is why systems that need both sign the claims first and then encrypt the resulting JWS.
  • Where do bearer tokens typically leak their payloads even when the connection is TLS-protected?
    After the wire. Reverse-proxy and gateway access logs, APM traces, browser localStorage or sessionStorage, mobile crash reports, and tokens pasted into support tickets all hold the token at rest. TLS ends at the terminating hop, so every one of those places can decode a JWS payload.
  • Does encrypting a token with JWE remove the need to keep lifetimes short?
    No. Both JWS and JWE tokens are bearer credentials: whoever holds the bytes can present them. Encryption hides the claims from third parties but does nothing about a stolen token being replayed by its holder, so short expiry, rotation, and sender-constraining mechanisms remain necessary.

A JWS is a postcard with a tamper-evident seal: everyone in the postal chain reads it, but nobody can alter it unnoticed. A JWE is the same message inside a sealed envelope only the addressee can open.

saying these in an interview costs you the question

  • Says a JWT is encrypted by default
  • Thinks Base64url encoding hides the payload
  • Claims the signature makes claims unreadable to clients
  • Puts personal or secret data in a signed JWT
  • Argues HTTPS makes the payload confidential everywhere

context

resolving links…