JWE 查看器与解密工具

The five parts of a JWE

A JWE (RFC 7516) is the encrypted counterpart of a JWS. Its compact serialization has five base64url parts separated by dots (RFC 7516 §7.1):

1. The protected header — JSON naming the algorithms, readable by anyone.
2. The encrypted key — the random content-encryption key (CEK), encrypted for the recipient. It is empty when there is nothing to transmit: with dir the shared key is the CEK, and with ECDH-ES the CEK is derived from the key agreement.
3. The initialization vector for the content encryption.
4. The ciphertext.
5. The authentication tag, which detects any change to the ciphertext, the IV or the protected header.

The JSON serialization (§7.2) carries the same pieces as named members and can address several recipients at once, each with its own encrypted copy of the CEK. The inspector reads all three forms: compact, flattened JSON and general JSON.

Two algorithms in every header

Every JWE combines two algorithms from RFC 7518:

• alg, key management (§4) — how the CEK reaches the recipient: RSA-OAEP and RSA-OAEP-256 encrypt it to an RSA public key; A128KW, A192KW, A256KW and their GCM variants wrap it with a shared key; ECDH-ES derives it from an elliptic-curve key agreement with the ephemeral key in the epk header, optionally wrapping it (ECDH-ES+A128KW); PBES2-HS256+A128KW and its siblings derive the wrapping key from a password with PBKDF2; dir uses a shared key as the CEK itself.
• enc, content encryption (§5) — how the payload is encrypted with the CEK: AES-GCM (A128GCM, A256GCM) or AES-CBC with HMAC-SHA-2 (A128CBC-HS256 … A256CBC-HS512). Both are authenticated: the protected header is part of the additional authenticated data, so changing alg or enc breaks the tag.

Without the key you can still read everything public: the header, the recipients, the key IDs, the sizes of the IV, ciphertext and tag. The inspector shows them as soon as you paste the token, and explains what the header says — a missing enc, an enc that is not integrity-protected, compression, a PBES2 iteration count that is too low or suspiciously high.

Decryption

With the key — a private key for RSA and ECDH-ES, a shared key for dir and AES key wrap, a password for PBES2 — the inspector decrypts with jose over the browser's Web Crypto API. In the JSON serialization it picks the recipient whose algorithm fits the key you gave. The plaintext is shown as text, as JSON when it parses, and as hex. When the plaintext is itself a signed JWT — a nested token, typical for OpenID Connect ID tokens encrypted to the client — its signature still has to be checked; take it to the JWT debugger.

A failed decryption is reported with one reason for a wrong key, a changed ciphertext and a changed tag alike. That is deliberate: telling them apart is exactly what padding-oracle attacks feed on, and libraries must not do it either.

What is refused, and why

• RSA1_5 (RSAES-PKCS1-v1_5) is parsed but never decrypted. Its padding has leaked plaintext to Bleichenbacher-style attacks for decades, and RFC 8725 §3.2 tells implementations to avoid it in favour of RSA-OAEP. If your issuer still uses it, that is the finding.
• Compression. zip DEF compresses the plaintext before encryption. The inspector decompresses it, but notes that compression lets ciphertext length leak information about the content (RFC 8725 §3.6) and can turn a small token into a very large plaintext.
• PBES2 iteration counts are capped, so a token with an absurd p2c cannot make the page spin for minutes.
• ECDH-ES ephemeral keys must be valid points on their curve; an invalid one is the invalid-curve attack of RFC 8725 §2.5, and Web Crypto refuses to import it.

Why only in your browser

A JWE protects data from everyone without the key — but the key, and the plaintext once decrypted, are exactly what must not travel. The inspector makes no network request with what you paste: the token, the key and the plaintext stay on the page. A share link carries the encrypted token alone, so a colleague can see its structure and decrypt it with a key of their own. Keys referenced by URL in the header (jku, x5u) are reported, never fetched.