HS256 vs RS256 em JWT: Diferenças e Quando Usar

Quando comparo HS256 vs RS256, não começo perguntando “qual algoritmo é mais forte?”. Primeiro pergunto: quem deve poder assinar tokens, quem só precisa verificar e quantos sistemas receberão material de chave?

Essa pergunta de arquitetura costuma decidir mais do que uma comparação abstrata de algoritmos.

Como penso em HS256

HS256 é HMAC com SHA-256. O mesmo segredo compartilhado participa de assinatura e verificação:

segredo compartilhado
   ├── assina JWT
   └── verifica JWT

Se entrego o segredo a uma API para que ela verifique tokens, também entrego material suficiente para essa API produzir novas assinaturas HMAC que outros sistemas com o mesmo segredo podem aceitar.

Isso pode ser totalmente adequado dentro de uma fronteira pequena e controlada. Só não chamo esse segredo de “verification-only”, porque criptograficamente ele não é.

Como penso em RS256

RS256 usa RSA PKCS#1 v1.5 com SHA-256 e separa os papéis:

chave privada → assina JWT
chave pública → verifica JWT

Uma API pode receber a chave pública e verificar tokens sem ganhar a capacidade de produzir uma assinatura RS256 válida.

Por isso, quando um provedor central de identidade emite tokens para várias APIs independentes, o modelo assimétrico costuma criar uma fronteira de confiança mais limpa.

Quando HS256 faz sentido

Considero HS256 quando:

• signer e verifier fazem parte de uma fronteira controlada pequena;
• distribuir e rotacionar o segredo é simples;
• não há necessidade de publicar uma chave de verificação;
• todos que recebem o segredo são intencionalmente confiados para assinar;
• simplicidade operacional tem valor real.

O segredo precisa ser forte e aleatório. A RFC 8725 alerta para HMAC com segredos fracos ou fáceis de memorizar, porque um token assinado pode permitir tentativas offline de descoberta do secret.

Quando RS256 é mais natural

Tendo a preferir RS256 quando:

• um authorization server central assina;
• muitas APIs precisam apenas verificar;
• verificadores não devem poder emitir tokens confiáveis;
• chaves públicas precisam ser distribuídas amplamente;
• rotação é feita por JWK/JWKS.

A chave privada fica como credencial de alto valor no signer. As APIs recebem apenas material público de verificação.

RS256 não é automaticamente “mais seguro”

Ambos podem ser implantados mal.

HS256 fica arriscado quando o secret é fraco, copiado para muitos serviços ou interpretado com encoding inconsistente.

RS256 fica arriscado quando a chave privada é mal protegida, o verifier aceita qualquer chave pública, a origem JWKS não está ligada ao issuer ou a seleção por kid é incorreta.

Segurança depende do modelo de confiança e da implementação completa, não apenas do nome do algoritmo.

Por que fixo algoritmos permitidos

Nunca quero que um JWT não confiável defina a política do verificador.

Se a aplicação espera RS256, configuro algo conceitualmente como:

algoritmos permitidos = [RS256]

Não faço:

algoritmo permitido = o que vier em header.alg

A RFC 8725 recomenda explicitamente restringir o conjunto de algoritmos. Isso ajuda a evitar classes históricas de confusão entre algoritmos e tipos de chave.

Distribuição de confiança com HS256

Imagine três APIs:

auth server -- segredo --> API A
            -- segredo --> API B
            -- segredo --> API C

Todos conhecem o mesmo segredo. Todos podem potencialmente produzir MACs aceitos pelos demais.

Isso não significa que HMAC esteja quebrado. Significa que preciso aceitar conscientemente essa relação de autoridade.

Distribuição de confiança com RS256

Com RS256:

auth server mantém chave privada
         |
         +--> API A recebe chave pública
         +--> API B recebe chave pública
         +--> API C recebe chave pública

Os verificadores não recebem a credencial de assinatura. Isso combina bem com um JWKS público e com rotação de chaves.

Onde entra kid

Durante rotação, um cabeçalho pode conter:

{
  "alg": "RS256",
  "kid": "2026-key-03"
}

Uso kid para selecionar a chave pública dentro de um conjunto já confiável. Não uso kid como prova de confiança.

O guia de JWT kid e o Validador JWKS mostram esse passo em detalhe.

Posso decodificar HS256 e RS256 sem chave?

Sim, em JWTs assinados comuns. O algoritmo muda a forma como a assinatura é criada e verificada, não a legibilidade de cabeçalho e payload.

Posso inspecionar ambos no Decodificador JWT sem secret ou chave privada. Material de chave passa a ser necessário quando quero provar quem assinou os dados.

Meu checklist HS256

Antes de usar ou depurar HS256, verifico:

• o segredo é forte e aleatório?
• quantos sistemas o recebem?
• todos eles podem ser confiados para assinar?
• o encoding do secret é consistente?
• o algoritmo permitido está fixado?
• existe estratégia de rotação?

Meu checklist RS256

Para RS256, verifico:

• onde a chave privada fica armazenada?
• como as chaves públicas são distribuídas?
• como kid funciona durante rotação?
• o JWKS pertence ao issuer confiável?
• o verifier rejeita algoritmos inesperados?
• iss, aud, exp e nbf são validados depois da assinatura?

Quando tenho um token e uma chave, uso o Verificador de Assinatura JWT. Se a assinatura falha, sigo o guia de assinatura JWT inválida antes de trocar de algoritmo até algo passar.

Minha regra prática é: HS256 funciona bem quando um segredo compartilhado é a fronteira de confiança desejada; RS256 é mais natural quando quero um signer central e muitos verificadores sem distribuir autoridade de assinatura.