JWE

JWE (JSON Web Encryption, RFC 7516) é o framework de criptografia na família JOSE (JSON Object Signing and Encryption), irmão do JWS. Onde JWS assina um payload (mantendo-o legível, mas com evidência de adulteração), JWE criptografa o payload (mantendo seu conteúdo confidencial).

Um token JWE em serialização compacta tem cinco segmentos separados por pontos em vez dos três do JWT:

1. Cabeçalho — JSON declarando os algoritmos de criptografia.
2. Chave de Criptografia de Conteúdo (CEK) Criptografada — a chave simétrica usada para o payload, ela própria criptografada com a chave do destinatário.
3. Vetor de Inicialização (IV) — nonce aleatório por criptografia.
4. Texto cifrado — o payload realmente criptografado.
5. Tag de autenticação — para modos AEAD; verifica que o texto cifrado não foi adulterado.

JWE usa um esquema híbrido: uma chave simétrica (a CEK) criptografa o payload (porque a criptografia simétrica é rápida), então uma chave assimétrica criptografa a CEK (porque a assimétrica é a única forma de manter chaves trocáveis sem um segredo compartilhado). Algoritmos padrão: RSA-OAEP para envolvimento de chave, A256GCM para criptografia de payload.

Quando usar JWE vs JWT: a maioria dos sistemas de autenticação usa JWT (assinado mas não criptografado) porque as claims não são secretas — um token contendo “sub: user_123, exp: ...” é seguro para leitura. Use JWE quando o token contém payload genuinamente sensível (registros médicos, detalhes financeiros, dados de roteamento apenas interno) e você não pode garantir que intermediários não o inspecionarão. A maioria dos sistemas modernos prefere manter dados sensíveis no servidor e usar um ID de sessão opaco curto em vez — mais simples do que JWE.

Exemplo prático

Um emissor de tokens precisa enviar uma referência de registro médico para um serviço downstream via navegador, mas o navegador não deve ser capaz de lê-la. O emissor cria um JWE: cabeçalho {"alg":"RSA-OAEP-256","enc":"A256GCM","cty":"JWT","kid":"recipient-2026"}, payload {"patient_id":"P-12345","record_id":"R-78910"}. O emissor gera uma CEK aleatória de 256 bits, criptografa o payload com AES-256-GCM sob essa chave (produzindo texto cifrado + tag de autenticação de 128 bits), e criptografa a CEK em si sob a chave pública RSA do destinatário. A saída são cinco segmentos codificados em base64url unidos por pontos — cerca de 600-800 bytes no total. O destinatário desembrulha em ordem reversa: descriptografa RSA a CEK usando sua chave privada, descriptografa AES-GCM o payload usando a CEK, verifica se a tag de autenticação corresponde. Qualquer adulteração em qualquer um dos cinco segmentos falha na verificação da tag de autenticação e o destinatário rejeita o token. O navegador que carrega o JWE no meio vê apenas base64 opaco — os IDs de paciente/registro são inacessíveis.

Quando e por que importa

JWE importa sempre que um token precisa atravessar intermediários não confiáveis enquanto carrega claims confidenciais — dados de pacientes, detalhes de roteamento financeiro, identificadores de usuário internos — e a arquitetura precisa usar um token em vez de uma sessão no servidor. O erro a evitar é buscar JWE primeiro quando uma arquitetura mais simples funciona: a maioria dos fluxos de autenticação é melhor servida por JWTs assinados contendo apenas referências (um ID de usuário, um ID de sessão) que intermediários podem ver sem dano, enquanto os dados sensíveis ficam no banco de dados do emissor. Use JWE quando intermediários são operacionalmente necessários para segurar o token, mas contratual ou legalmente restritos de lê-lo — SSO federado entre organizações, troca de dados de saúde entre provedores, alguns fluxos PSD2 de open banking. O segundo erro é escolha incorreta de algoritmo: RSA-OAEP com SHA-1 está obsoleto, RSA-OAEP-256 é a recomendação atual; A128CBC-HS256 ainda é aceitável, mas A256GCM é preferido para novas implantações. Referência: RFC 7518 — Algoritmos Web JSON.

JOSE aninhado — assinar e depois criptografar: para tokens que precisam de autenticidade (origem comprovável) e confidencialidade, o padrão é assinar-então-criptografar: o payload é primeiro envolvido em um JWS, então o JWS inteiro se torna o payload de um JWE. O campo de cabeçalho cty: "JWT" no JWE externo sinaliza ao analisador que o conteúdo descriptografado é em si um token JOSE a ser verificado. A ordem inversa (criptografar depois assinar) é menos segura porque a assinatura seria sobre texto cifrado que poderia ser reproduzido entre destinatários. A maioria das plataformas SSO empresariais que usam JWE (tokens de federação do Microsoft Azure AD, algumas APIs bancárias) enviam assinar-então-criptografar como padrão. Referência: RFC 7516 — JSON Web Encryption.