JWE

JWE (JSON Web Encryption, RFC 7516) est le cadre de chiffrement de la famille JOSE (JSON Object Signing and Encryption), sibling de JWS. Là où JWS signe une charge utile (la gardant lisible mais détectable en cas de falsification), JWE chiffre la charge utile (rendant son contenu confidentiel).

Un jeton JWE en sérialisation compacte comporte cinq segments séparés par des points au lieu des trois de JWT :

1. En-tête — JSON déclarant les algorithmes de chiffrement.
2. Clé de chiffrement du contenu (CEK) chiffrée — la clé symétrique utilisée pour la charge utile, elle-même chiffrée avec la clé du destinataire.
3. Vecteur d’initialisation (IV) — nonce aléatoire par chiffrement.
4. Texte chiffré — la charge utile réellement chiffrée.
5. Tag d’authentification — pour les modes AEAD ; vérifie que le texte chiffré n’a pas été falsifié.

JWE utilise un schéma hybride : une clé symétrique (la CEK) chiffre la charge utile (car le chiffrement symétrique est rapide), puis une clé asymétrique chiffre la CEK (car l’asymétrique est le seul moyen de rendre les clés échangeables sans secret partagé). Algorithmes standard : RSA-OAEP pour l’encapsulation de clé, A256GCM pour le chiffrement de la charge utile.

Quand utiliser JWE vs JWT : la plupart des systèmes d’authentification utilisent JWT (signé mais non chiffré) car les claims ne sont pas secrets — un jeton contenant “sub: user_123, exp: ...” peut être lu sans problème. Utilisez JWE lorsque le jeton contient une charge utile genuinement sensible (dossiers médicaux, données financières, données de routage internes) et que vous ne pouvez pas garantir que les intermédiaires ne l’inspecteront pas. La plupart des systèmes modernes préfèrent garder les données sensibles côté serveur et utiliser un identifiant de session opaque court — plus simple que JWE.

Exemple concret

Un émetteur de jetons doit envoyer une référence à un dossier médical à un service en aval via le navigateur, mais le navigateur ne doit pas pouvoir le lire. L’émetteur crée un JWE : en-tête {"alg":"RSA-OAEP-256","enc":"A256GCM","cty":"JWT","kid":"recipient-2026"}, charge utile {"patient_id":"P-12345","record_id":"R-78910"}. L’émetteur génère une CEK 256 bits aléatoire, chiffre la charge utile avec AES-256-GCM sous cette clé (produisant le texte chiffré + tag d’authentification 128 bits), et chiffre la CEK elle-même sous la clé publique RSA du destinataire. La sortie est cinq segments encodés en base64url joints par des points — environ 600 à 800 octets au total. Le destinataire déchiffre en sens inverse : déchiffrement RSA de la CEK avec sa clé privée, déchiffrement AES-GCM de la charge utile avec la CEK, vérification que le tag d’authentification correspond. Toute falsification de l’un des cinq segments fait échouer la vérification du tag et le destinataire rejette le jeton. Le navigateur transportant le JWE entre les deux ne voit qu’un base64 opaque — les ID patient/dossier sont inaccessibles.

Quand et pourquoi c’est important

JWE importe chaque fois qu’un jeton doit traverser des intermédiaires non fiables tout en transportant des claims confidentiels — données patients, détails de routage financier, identifiants d’utilisateurs internes — et que l’architecture doit utiliser un jeton plutôt qu’une session côté serveur. L’erreur à éviter est de se tourner vers JWE en premier quand une architecture plus simple fonctionne : la plupart des flux d’authentification sont mieux servis par des JWT signés ne contenant que des références (un ID utilisateur, un ID de session) que les intermédiaires peuvent voir sans risque, tandis que les données sensibles restent dans la base de données de l’émetteur. Utilisez JWE lorsque les intermédiaires sont opérationnellement requis pour détenir le jeton mais contractuellement ou légalement restreints à sa lecture — SSO fédéré entre organisations, échange de données de santé entre prestataires, certains flux PSD2 de banque ouverte. La deuxième erreur est le mauvais choix d’algorithme : RSA-OAEP avec SHA-1 est déprécié, RSA-OAEP-256 est la recommandation actuelle ; A128CBC-HS256 est encore acceptable mais A256GCM est préféré pour les nouveaux déploiements. Référence : RFC 7518 — Algorithmes Web JSON.

JOSE imbriqué — signer puis chiffrer : pour les jetons nécessitant à la fois l’authenticité (origine prouvable) et la confidentialité, le schéma standard est signer-puis-chiffrer : la charge utile est d’abord enveloppée dans un JWS, puis le JWS entier devient la charge utile d’un JWE. Le champ d’en-tête cty: "JWT" dans le JWE externe signale au parseur que le contenu déchiffré est lui-même un jeton JOSE à vérifier. L’ordre inverse (chiffrer puis signer) est moins sécurisé car la signature porterait sur un texte chiffré pouvant être rejoué auprès d’autres destinataires. La plupart des plateformes SSO d’entreprise utilisant JWE (jetons de fédération Microsoft Azure AD, certaines API bancaires) livrent le schéma signé-puis-chiffré en standard. Référence : RFC 7516 — JSON Web Encryption.