Случайный ключ шифрования содержимого (CEK) шифрует полезную нагрузку алгоритмом AEAD, например A256GCM или A128CBC-HS256 (enc); до получателя CEK доходит через алгоритм управления ключами (alg): RSA-OAEP-256, ECDH-ES (прямое согласование, часть с зашифрованным ключом пуста) или ECDH-ES+A256KW, A256KW с общим ключом либо dir для заранее согласованного CEK. Защищённый заголовок служит связанными данными (associated data) AEAD, поэтому изменить его нельзя.
JWE обеспечивает конфиденциальность по отношению к получателю, но с ECDH-ES или RSA-OAEP не даёт аутентификации отправителя: создать такой JWE может любой, у кого есть открытый ключ. Во вложенных JWT сначала подписывают, а затем шифруют подписанный JWT, указывая cty со значением JWT. Известные ловушки: точки недопустимой кривой в ECDH-ES (проверяйте epk), PBES2 с огромным числом итераций как способ вызвать отказ в обслуживании и оракул дополнения в RSA1_5; меры защиты перечислены в RFC 8725.
Большинству API JWE не нужен, потому что TLS уже защищает канал; он полезен для токенов, которые проходят через недоверенных посредников или хранятся у клиентов. Инспектор JWE показывает заголовок и структуру без расшифровки.