# JWE > JWE (JSON Web Encryption) é um padrão aberto para criptografar dados em formato JSON e transportá-los com segurança entre sistemas. Ele embala uma informação de modo que apenas quem possui a chave correta consiga lê-la, garantindo confidencialidade. É muito usado para proteger tokens e dados sensíveis trafegados por APIs. **Também conhecido como:** JSON Web Encryption, Token JWE, JWT criptografado, Criptografia Web JSON, JWE **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** J ## 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. ## Perguntas frequentes ### Dá para ler o conteúdo de um JWE decodificando o Base64? Não. Ao contrário do JWS, a parte de conteúdo do JWE está cifrada. Decodificar o Base64 só revela bytes ilegíveis. Apenas o cabeçalho, que indica os algoritmos usados, pode ser lido sem a chave. ### Todo JWT é um JWE? Não. A maioria dos JWT usados em APIs é do tipo JWS, ou seja, apenas assinada. Um JWT só é JWE quando seu conteúdo é criptografado, o que se reconhece pelas cinco partes separadas por pontos, em vez de três. ### JWE garante quem enviou a mensagem? Não necessariamente. O JWE garante confidencialidade e detecta alterações, mas, dependendo do algoritmo, qualquer pessoa com a chave pública do destinatário pode criar um JWE. Para comprovar a origem, combine com assinatura JWS. ### Preciso usar JWE para integrar com uma API fiscal? Depende da API. Muitas integrações funcionam apenas com HTTPS e um token Bearer ou API Key. O JWE é usado quando a documentação exige ou quando há dados sensíveis que precisam permanecer protegidos além da conexão. ## Termos relacionados - [JWS](https://conota.dev/glossario/jws.md) - [JWT](https://conota.dev/glossario/jwt.md) - [TLS](https://conota.dev/glossario/tls.md) - [Token de autenticação](https://conota.dev/glossario/token-de-autenticacao.md) - [Gerenciamento de segredos](https://conota.dev/glossario/gerenciamento-de-segredos.md) - [Key management service](https://conota.dev/glossario/key-management-service.md) --- Fonte: [JWE](https://conota.dev/glossario/jwe/) · Atualizado em 2026-10-22