Une clé de chiffrement de contenu (CEK) aléatoire chiffre la charge utile avec un AEAD tel que A256GCM ou A128CBC-HS256 (enc) ; la CEK parvient au destinataire par l’algorithme de gestion des clés (alg) : RSA-OAEP-256, ECDH-ES (accord direct, partie de clé chiffrée vide) ou ECDH-ES+A256KW, A256KW avec une clé partagée, ou dir pour une CEK prépartagée. L’en-tête protégé constitue les données associées de l’AEAD : il ne peut donc pas être modifié.
Un JWE assure la confidentialité vis-à-vis de son destinataire, mais aucune authentification de l’expéditeur avec ECDH-ES ou RSA-OAEP : quiconque possède la clé publique peut en créer un. Un JWT imbriqué est d’abord signé, puis le JWT signé est chiffré, avec cty à JWT. Les pièges connus sont les points sur courbe invalide dans ECDH-ES (validez epk), PBES2 avec des nombres d’itérations énormes comme vecteur de déni de service, et l’oracle de remplissage RSA1_5 ; la RFC 8725 liste les parades.
La plupart des API n’ont jamais besoin de JWE, car TLS protège déjà le canal ; JWE est utile pour les jetons qui transitent par des intermédiaires non fiables ou qui sont stockés par les clients. L’inspecteur JWE affiche l’en-tête et la structure sans déchiffrer.