New CS proposal: Javascript Object Signing and Encryption (JOSE)

[craigjbass]

What is the proposed Cheat Sheet about?

Javascript Object Signing and Encryption. In particular JWE.

What security issues are commonly encountered related to this area?

• How to configure JWE implementations to be secure.
• Recommended encryption algorithms
• Traps e.g. using the same asymmetric keys between JWT and JWE. In what circumstances is this bad?

What is the objective of the Cheat Sheet?

To help people implement secure JWE implementations.

What other resources exist in this area?

Writing this because there seems to be very little guidance online, and some of it is contradictory.

The owasp cheatsheet has some guidance on best use of JWT (object signing) but no guidance on the usage of JWE.

[szh]

Can you please provide some example topics that you'd like to have added, that aren't already covered in the JWT cheat sheet?

[craigjbass]

• What algorithms are considered best practice? The algorithms for JWT are different to JWE.
• Asymetric vs Symmetric keys
• Clearing up the different between JWT and JWE - signing vs encryption.
• The differences between RSA, RSA-OAEP, AKW, A-GC-MKW, EdDSA, X25519/Curve25119, ECDH-ES+A*KW
• Common use cases of JWE, and recommendations for hardening
  • Sessions
  • Inter-service communication
  • Authentication flows

[szh]

Cool, seems like a good idea. Any input from the other maintainers?

[jmanico]

I think this is a great idea!!

[szh]

Alright then! @craigjbass do you want to take this on?

[mackowski]

@craigjbass do you want to work on this?

[craigjbass]

I think I would be able to write something, but I would need some help!

Some of the topics I want to cover, I'm not sure I know the answer to.

[caffeine-rohit]

The existing JWT Cheat Sheet primarily covers token security but does not address JWE in detail. While it discusses risks like weak secrets, revocation strategies, and hashing vulnerabilities, but it lacks:

Encryption Methods: No guidance on encrypting JWTs using JWE.
Algorithm Selection: No recommendations on secure encryption algorithms (e.g., AES-GCM, RSA-OAEP).
Key Management: No best practices for securely handling encryption keys.
Implementation Guidance: No practical steps for developers to integrate JWE securely.
Common Pitfalls: No warnings about common mistakes in JWE implementation.
A dedicated JWE cheat sheet would fill these gaps and help developers use encrypted JWTs securely. Is anyone already working on this, or would anyone like to collaborate ?
@jmanico @szh @mackowski

[jmanico]

When using a JWT for session management I suggest not placing sensitive data in a JWT and therefor you do not need to encrypt it.

If you want to talk about JWE, I would suggest a second concise cheatsheet. I see a lot of JWE used in the health industry.

[mackowski]

Yes new cheatsheet on JWE would be awesome!

[caffeine-rohit]

I’ve put together a detailed JWE Cheat Sheet, covering JWE structure, secure algorithm choices (AES-GCM, RSA-OAEP, ECDH-ES), key management best practices, implementation in Python & Java, hardening techniques, and common pitfalls. It also includes a JWE vs. PASETO comparison.

Before raising a PR, I’d appreciate any technical feedback or improvements to ensure it aligns with OWASP standards. If everything looks good, I’m ready to submit the PR.

Here’s the latest version: JWE Cheat Sheet

Looking forward to your thoughts! 🚀
@jmanico @szh @mackowski

[jmanico]

Please also take a look at https://github.com/OWASP/ASVS/blob/master/5.0/en/0x14-V6-Cryptography.md to make sure your work is in sync with ASVS

[randomstuff]

Yes, JWE provides many very different key management methods. It is not easy to understand all the cases and know which combinations are interesting/safe to use.

[randomstuff]

@caffeine-rohit

AES-256-GCM | Symmetric | Fast encryption for internal services

RSA-OAEP | Asymmetric | Secure communication between different entities

ECDH-ES | Asymmetric | Efficient encryption for large-scale applications

Wouldn't it be easier to use public key cryptography for internal services as well? It avoids the n×(n-1) key distribution problem if I have many services. Moreover it reduces the risk of the encryption secret (and therefore the JWT plaintext) being leaked.

On the other hand, ECDH-ES might be vulnerable to quantum computers.

Why would I use RSA-OAEP instead of ECDH-ES? The latter is faster at equivalent security level.

If I use AES-256-GCM as a key management solution, should I use "direct" AES-256-GCM instead?

If I use ECDH-ES, should I use ECDH-ES+A128KW and friends? (I think it is only useful if I want to support multi-recipient JWT).

Also, why would I want to use PBES2?

Use authenticated encryption (GCM mode) for integrity verification

This one is weird as all JWE encryption mechanisms ("enc") are actually AEADs.

Do NOT store JWE in client-side storage (localStorage, sessionStorage)

The JWE is encrypted. Is it bad if I am storing it client-side? (Does this only apply to JWE which are actually JWTs?)

Replay attacks | Implement nonce-based validation

Why kind of nonce are we talking about? I don't think we want to do what I understand is said here.

Expired tokens | Set short expiration times & enforce refresh policies

Man-in-the-middle attacks | Use TLS/SSL for JWE transmission

These are more JWT concerns as well.

JEW Implementation in Python (PyJWT & Cryptography)

These ones are not complete at all :)

return {'iv': iv.hex(), 'ciphertext': ciphertext.hex()}

They should be base64urlencoded.

---

Some missing bits:

• don't reuse AES nonce/IVs;
• don't reuse CEKs (content encryption keys);
• don't reuse (ECDH) ephemeral public keys;
• don't use the same secret key between multiple peers;
• Guidance about the correct way to combine JWE with JWS (especially in JWT).
• The JWT specification allows using JWT which are JWE only. In this safe to do? When?
• Best practice for multi-recipient JWE.
• What should I do with the "apv" and "apu" header parameters?

[randomstuff]

Also don't compress data before encryption.

[raphaelahrens]

What is missing is that alg and enc can be attacker controlled and both need to be checked by all consumers so that both values match with the key.

[caffeine-rohit]

I have carefully analyzed all the comments and taken them into account. Before making a draft PR, I will ensure that the sheet is refined to align with the highest standards, covering all necessary aspects comprehensively.

[jmanico]

I have carefully analyzed all the comments and taken them into account. Before making a draft PR, I will ensure that the sheet is refined to align with the highest standards, covering all necessary aspects comprehensively.

I like your attitude! +100

[caffeine-rohit]

I appreciate all the valuable feedback and guidance provided on the initial draft of the JSON Web Encryption (JWE) Cheat Sheet. Based on your insights, I have carefully addressed each suggestion and incorporated the necessary improvements in my Draft PR

🔹 Key Enhancements Implemented in the Updated Cheat Sheet:

✔ alg and enc Header Validation → Ensured all consumers validate both values to prevent attacker-controlled downgrades.
✔ JWE + JWS Combination → Explained how to use JWE for encryption & JWS for integrity to enhance security.
✔ Handling apv and apu in ECDH-ES → Added clear guidance on using these parameters for secure key derivation.
✔ JWE-Only JWT Considerations → Clarified when JWE-only tokens are safe & when additional integrity mechanisms are needed.
✔ Secure Key Management → Reinforced best practices for key rotation, storage in HSMs, and preventing nonce/IV reuse.
✔ Avoiding Common Pitfalls → Highlighted risks like token storage in localStorage, compression vulnerabilities, and long-lived JWEs.
✔ ASVS Compliance → Ensured alignment with OWASP ASVS cryptography standards for robust security.

With these updates, the cheat sheet now provides a structured, security-first approach to implementing JWE effectively.

I would love your final review and feedback on the PR to ensure that all improvements align with best practices. Please let me know if there are any additional refinements required before we finalize the contribution.

Looking forward to your insights! 🚀

@jmanico @szh @mackowski