JWE

O que é JWE, explicado de forma simples?

Pense no JWE como um envelope lacrado e opaco. Quem intercepta o envelope vê que ele existe, mas não consegue ler o que está dentro. Só o destinatário, que tem a chave certa, abre o envelope e lê a mensagem.

Tecnicamente, o JWE é uma especificação publicada pela IETF, a mesma organização que padroniza vários protocolos da internet. Ele faz parte de uma família de padrões chamada JOSE (JSON Object Signing and Encryption), que também inclui o JWS (assinatura) e o JWT (tokens).

Como funciona um JWE?

Na forma mais comum, chamada serialização compacta, um JWE é um texto com cinco partes separadas por pontos: o cabeçalho, a chave de conteúdo criptografada, o vetor de inicialização, o texto cifrado (os dados protegidos) e uma etiqueta de autenticação, que permite detectar se algo foi alterado no caminho.

O cabeçalho informa dois algoritmos. O campo alg indica como a chave que protege o conteúdo foi tratada, por exemplo com RSA-OAEP ou com uma chave simétrica compartilhada. O campo enc indica como o conteúdo em si foi cifrado, por exemplo com AES-GCM.

Esse modelo é chamado de criptografia híbrida: uma chave aleatória e rápida cifra os dados, e essa chave, por sua vez, é protegida com a chave do destinatário. Assim se combina desempenho com segurança.

Qual a diferença entre JWE, JWS e JWT?

O JWS assina os dados: garante quem os emitiu e que não foram alterados, mas o conteúdo continua legível por qualquer pessoa, bastando decodificar o Base64. O JWE criptografa os dados: o foco é esconder o conteúdo de quem não tem a chave.

O JWT é um formato de token que carrega informações, como identificador do usuário e prazo de validade. Um JWT pode ser construído como JWS (assinado) ou como JWE (criptografado). Quando é preciso as duas garantias, é comum assinar primeiro e depois criptografar o resultado, o chamado JWT aninhado.

Para que serve o JWE em integrações fiscais?

Em integrações com APIs fiscais circulam dados delicados: identificação de empresas emissoras, informações de clientes, tokens de acesso e até senhas de certificados digitais. O JWE é uma opção para proteger esses dados quando eles precisam passar por sistemas intermediários, ficar armazenados temporariamente ou ser lidos apenas por um serviço específico.

Um exemplo típico é um token de acesso que carrega informações internas, como o identificador do tenant ou permissões. Se o token for criptografado com JWE, o sistema cliente consegue usá-lo normalmente, mas não consegue ler nem expor o que há dentro dele.

JWE substitui o HTTPS?

Não. O HTTPS, que usa TLS, protege a conexão entre dois pontos enquanto os dados estão em trânsito. Quando a mensagem chega ao destino, ou passa por um proxy, fila ou log, ela deixa de estar protegida pelo TLS.

O JWE protege a própria mensagem, independentemente do canal. Por isso os dois são complementares: o HTTPS continua obrigatório em qualquer API fiscal, e o JWE acrescenta uma camada extra quando o conteúdo precisa permanecer confidencial além da conexão.

Quais cuidados são importantes ao usar JWE?

O ponto mais crítico é a gestão de chaves. De nada adianta criptografar se a chave privada fica exposta no código-fonte ou em variáveis mal protegidas. O recomendado é guardá-la em um cofre de segredos ou serviço de gerenciamento de chaves e fazer rotação periódica.

Também é importante usar bibliotecas consolidadas em vez de implementar a criptografia manualmente, aceitar apenas algoritmos previamente definidos pelo servidor e validar prazo de expiração e emissor do conteúdo após descriptografar.

Exemplos de JWE

• Um ERP recebe da API fiscal um token de acesso no formato JWE. O ERP apenas o envia no header de autenticação das próximas requisições, sem conseguir ler as permissões e dados de tenant que estão dentro dele.
• Uma plataforma de vendas precisa repassar a senha de um certificado digital A1 a um serviço interno de emissão. Em vez de enviá-la em texto puro no payload, a senha é empacotada em um JWE que só o serviço de emissão consegue abrir.
• Um marketplace gera links temporários para o lojista baixar XML e PDF de notas. O parâmetro do link é um JWE com o identificador do documento e a data de expiração, impedindo que alguém descubra ou altere esses dados.
• Um time de desenvolvimento usa JWT aninhado: o token é assinado com JWS para garantir a origem e depois criptografado com JWE para ocultar o conteúdo.