JWS

JWS (JSON Web Signature, RFC 7515) é o framework de assinatura criptográfica sobre o qual JWT é construído. Um JWS tem três partes unidas por pontos: cabeçalho.payload.assinatura, cada segmento codificado em base64url. O cabeçalho é JSON declarando o algoritmo; o payload pode ser quaisquer bytes (tipicamente, mas não necessariamente JSON); a assinatura é calculada sobre o cabeçalho e o payload unidos por pontos usando o algoritmo declarado.

A relação com JWT: todo JWT é um JWS cujo payload é obrigado a ser um objeto JSON de claims. Mas o JWS em si é mais geral — o payload pode ser binário bruto, um documento XML ou qualquer outra sequência de bytes. Quando você vê um token de três partes separadas por pontos que não decodifica em JSON em base64 no segmento do meio, é um JWS, não um JWT.

Algoritmos comuns: HS256 (HMAC-SHA256, chave simétrica), RS256 (RSA-SHA256, assimétrico), ES256 (ECDSA-P256-SHA256, assimétrico). O perigoso algoritmo “none” significa “sem assinatura” — legal por especificação, mas sempre a ser rejeitado no servidor. Os verificadores de produção também devem verificar explicitamente que o algoritmo declarado no cabeçalho corresponde ao algoritmo esperado para a chave.

JWS tem duas serializações: compacta (o formato separado por pontos que JWT usa) e JSON (um envelope JSON envolvendo as mesmas três partes, suportando múltiplas assinaturas). A forma compacta é o que quase todas as APIs usam; a forma JSON é rara fora de protocolos específicos.

Exemplo prático

Tome o JWS eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyJ9.4Adcj3UFYzPUVaHwte4eBI6vsjOvpz0yiwIM0F7sjuk. Decodifique o cabeçalho (primeiro segmento): {"alg":"HS256"} — assinatura HMAC-SHA256. Decodifique o payload (segundo segmento): {"sub":"user_123"}. A assinatura (terceiro segmento) é HMAC-SHA256 de eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyJ9 usando a chave secreta compartilhada. O verificador reconstrói o HMAC e compara usando comparação em tempo constante; incompatibilidade → rejeitar. Agora compare com RS256: mesma estrutura, mas a assinatura é RSA-SHA256, o emissor assina com uma chave privada e os verificadores verificam com a chave pública. Os bytes do token são mais longos (assinaturas RSA são ~342 caracteres base64 para uma chave de 2048 bits vs 43 para HMAC-SHA256), mas a semântica de validação é idêntica do ponto de vista do chamador.

Quando e por que importa

JWS importa toda vez que um serviço emite, transmite ou aceita um JWT — o que em 2026 é a maioria das APIs. Os erros que produziram CVEs repetidamente na última década: (1) não validar a assinatura de forma alguma, tratando o payload como confiável simplesmente porque foi analisado como JSON; (2) aceitar alg: none, que remove completamente a assinatura; (3) aceitar qualquer algoritmo que o token declare, habilitando o ataque de confusão HS256-com-chave-pública-RSA; (4) não validar exp, permitindo replay de tokens há muito expirados; (5) não validar iss e aud, aceitando tokens emitidos para serviços completamente diferentes. A linha de base defensiva: fixe o algoritmo esperado na chamada de verificação, obtenha a chave de verificação de uma fonte confiável (geralmente uma URL JWKS na lista de permissões em tempo de configuração, não o próprio jku do token), e valide exp, iss e aud como verificações pós-assinatura separadas. Referência: RFC 8725 — Melhores Práticas Atuais para JWT.

Por que o ataque de confusão de algoritmo ainda aparece em CVEs: uma família persistente de vulnerabilidades JWS envolve um servidor que pergunta à biblioteca JWT “este token é válido?” e deixa a biblioteca escolher o algoritmo de verificação do próprio cabeçalho do token. Um atacante que conhece a chave pública RSA do servidor (que, por definição, é pública) pode criar um token assinado com HMAC-SHA256 usando os bytes da chave pública RSA como segredo HMAC, definir alg: HS256 no cabeçalho, e muitas bibliotecas o verificarão. A mitigação é bloquear a verificação para o algoritmo que você espera — passá-lo como argumento explícito para a chamada de verificação em vez de deixar o token nomeá-lo. A divulgação de 2015 disso contra várias bibliotecas principais (o jsonwebtoken do Node, pyjwt do Python, várias implementações Java) é o conto preventivo padrão.

JWS destacado — quando o payload é grande demais para incorporar: RFC 7797 define um modo de “payload destacado” onde o segmento do meio está vazio e o payload é transmitido fora de banda (por exemplo, como o corpo HTTP, enquanto o JWS fica em um cabeçalho). É assim que algumas APIs financeiras assinam grandes corpos de requisição sem recodificar em base64 megabytes de JSON. A assinatura ainda é calculada sobre os bytes originais do payload; apenas o formato de transmissão muda. Referência: RFC 7515 — JSON Web Signature.