Assinatura de tokens JWT: HS256, RS256 e ES256 na prática

O algoritmo JWT é o método criptográfico usado para assinar (e, em alguns casos, cifrar) um JSON Web Token. Ele fica indicado no campo alg do cabeçalho do token e define como o servidor comprova que o conteúdo não foi alterado. Os mais usados são HS256, RS256 e ES256, e a escolha entre eles depende de quem precisa gerar e de quem precisa apenas validar os tokens.

Em resumo: se um único serviço emite e valida, HS256 com uma chave secreta forte resolve. Se vários serviços precisam validar tokens emitidos por um servidor central, use um algoritmo assimétrico como RS256 ou ES256. E, em qualquer cenário, o servidor deve fixar quais algoritmos aceita, em vez de confiar no que o token diz.

Como um JWT é montado

Um JWT tem três partes separadas por ponto: cabeçalho, payload e assinatura. As duas primeiras são objetos JSON codificados em Base64URL. A terceira é o resultado do algoritmo aplicado sobre as duas primeiras.

• Cabeçalho (header): informa o tipo do token e o algoritmo, por exemplo {"alg":"HS256","typ":"JWT"}.
• Payload: traz as claims, como sub (identificador do usuário), exp (expiração) e iat (momento da emissão).
• Assinatura: gerada a partir de base64url(header) + "." + base64url(payload) com a chave e o algoritmo escolhidos.

Um ponto que confunde muita gente: o payload não é criptografado em um JWT assinado comum (JWS). Qualquer pessoa com o token consegue decodificá-lo e ler o conteúdo. A assinatura garante integridade e autenticidade, não sigilo. Por isso, senhas, dados de cartão ou informações sensíveis não devem ir no payload.

Principais tipos de algoritmo JWT

A especificação JWA (RFC 7518) lista os algoritmos suportados. Na prática, eles se dividem em três famílias.

HMAC (HS256, HS384, HS512)

Usam uma única chave secreta compartilhada, tanto para assinar quanto para verificar. São rápidos e simples de configurar. A desvantagem é que todo serviço que valida o token também passa a ter o poder de emiti-lo, já que conhece a mesma chave.

RSA (RS256, RS384, RS512, PS256)

Usam um par de chaves: a privada assina e a pública verifica. O servidor de autenticação guarda a privada, e as APIs recebem apenas a pública. As variantes PS usam o padding RSA-PSS, considerado mais robusto que o PKCS#1 v1.5 das variantes RS.

Curvas elípticas (ES256, ES384, EdDSA)

Também são assimétricos, mas com chaves e assinaturas bem menores que as de RSA para um nível de segurança comparável. Isso reduz o tamanho do token e o custo de processamento. O EdDSA (com Ed25519) vem ganhando espaço nas bibliotecas mais recentes.

Como escolher o algoritmo JWT certo para o seu projeto

A pergunta central é: quantas partes do sistema precisam validar o token e em quantas você confia para emiti-lo?

1. Uma aplicação só, backend único: HS256 atende bem, desde que a chave tenha pelo menos 256 bits aleatórios e não fique no código-fonte.
2. Vários serviços ou terceiros validando: prefira RS256 ou ES256. Você distribui a chave pública (muitas vezes via endpoint JWKS) sem expor a capacidade de emitir tokens.
3. Integração com provedores de identidade: siga o que o provedor usa. A maioria dos serviços compatíveis com OpenID Connect trabalha com RS256 por padrão.
4. Tokens muito trafegados ou dispositivos limitados: ES256 ou EdDSA ajudam a manter o token enxuto.

Exemplo prático em Node.js

O trecho abaixo usa a biblioteca jsonwebtoken. Repare que, na verificação, a lista de algoritmos aceitos é informada explicitamente.

const jwt = require('jsonwebtoken');

const segredo = process.env.JWT_SECRET;

// Emissão
const token = jwt.sign(
  { sub: '123', papel: 'admin' },
  segredo,
  { algorithm: 'HS256', expiresIn: '15m' }
);

// Verificação
try {
  const dados = jwt.verify(token, segredo, { algorithms: ['HS256'] });
  console.log(dados.sub);
} catch (erro) {
  console.error('Token inválido:', erro.message);
}

Com RS256, a diferença é que sign recebe a chave privada e verify recebe a chave pública, com algorithms: ['RS256'].

Falhas de segurança mais comuns

Boa parte dos incidentes com JWT não vem do algoritmo em si, e sim de configurações erradas na validação.

Aceitar o algoritmo “none”

Algumas bibliotecas antigas aceitavam tokens com alg: none, ou seja, sem assinatura. Um atacante podia montar um payload qualquer e ser aceito. Fixar a lista de algoritmos permitidos elimina o problema.

Confusão entre algoritmos

Se o servidor espera RS256, mas aceita qualquer alg, um atacante pode enviar um token HS256 assinado com a chave pública (que é pública) usada como segredo HMAC. Bibliotecas vulneráveis validavam esse token. De novo, a defesa é não deixar o token decidir o algoritmo.

Segredo fraco

Chaves HMAC curtas ou previsíveis podem ser quebradas por força bruta offline, já que o atacante tem o token e pode testar senhas à vontade. Gere a chave com um gerador criptográfico e guarde em variável de ambiente ou cofre de segredos.

Tokens sem expiração

Um token sem exp vale para sempre. Se vazar, não há como limitá-lo sem trocar a chave de todos. Use tokens de acesso curtos e refresh tokens com possibilidade de revogação.

Boas práticas de implementação

• Defina no servidor a lista fechada de algoritmos aceitos.
• Valide sempre exp, nbf, iss e aud quando fizer sentido para o seu fluxo.
• Planeje a rotação de chaves usando o campo kid no cabeçalho.
• Transmita tokens apenas por HTTPS. Um bom começo é entender como funciona a hospedagem do seu site e onde o certificado é configurado.
• No navegador, avalie cookies HttpOnly e Secure em vez de localStorage, para reduzir o impacto de ataques XSS.
• Use bibliotecas mantidas e atualizadas; não implemente assinatura manualmente.

Se você está começando na área, vale revisar algoritmos e lógica de programação antes de mergulhar em criptografia aplicada. Conceitos como hash e funções determinísticas ficam bem mais fáceis de entender com essa base.

Perguntas frequentes

O que é o algoritmo em um JWT?

É o método criptográfico indicado no campo alg do cabeçalho, usado para gerar e verificar a assinatura. Ele garante que o conteúdo do token não foi alterado depois da emissão.

HS256 é inseguro?

Não, desde que a chave seja longa, aleatória e bem guardada. O limite dele é arquitetural: todos que validam também conseguem emitir tokens, o que não serve para ambientes com muitos serviços.

Qual a diferença entre JWT simétrico e assimétrico?

No simétrico, a mesma chave assina e verifica. No assimétrico, a chave privada assina e a pública verifica, permitindo distribuir a validação sem distribuir o poder de emitir tokens.

Dá para ler o conteúdo de um JWT sem a chave?

Sim. O payload de um JWT assinado é apenas codificado em Base64URL, não cifrado. Para sigilo, é preciso usar JWE, que é a variante criptografada.

O JWT substitui a sessão no servidor?

Pode substituir, mas traz outros desafios, como revogação de tokens antes da expiração. Muitos sistemas combinam tokens curtos com uma lista de revogação ou refresh tokens armazenados no servidor.

O que levar dessa leitura

Escolher o algoritmo JWT é, antes de tudo, uma decisão sobre quem pode emitir e quem pode validar tokens. HS256 funciona bem em sistemas simples; RS256, ES256 e EdDSA são mais adequados quando há vários serviços envolvidos. Com a lista de algoritmos fixada no servidor, expiração curta e chaves bem guardadas, o JWT cumpre bem o papel de autenticação.