A escolha entre HS256 e RS256 se resume a uma pergunta: quem precisa verificar seus tokens? HS256 usa uma única chave secreta para assinar e verificar, o que é simples e rápido, mas significa que todo verificador também tem o poder de criar tokens. RS256 usa uma chave privada para assinar e uma chave pública separada para verificar, permitindo que você distribua a chave pública para qualquer um sem dar a capacidade de falsificar. Entenda essa diferença e o resto da decisão se encaixa.
A maioria das comparações para em "simétrico versus assimétrico" e deixa você descobrir qual o seu sistema realmente precisa. Este guia oferece uma regra de decisão ligada à sua arquitetura, diferenças reais no nível de código, a troca de desempenho que raramente importa e o único erro de configuração que transforma qualquer algoritmo em uma brecha de falsificação.
HS256 vs RS256 de Relance#
Ambos são algoritmos de assinatura de JSON Web Token definidos na especificação JWA (RFC 7518). Eles protegem a mesma coisa: a integridade de um token, para que um servidor possa confiar que as declarações internas (ID do usuário, função, expiração) não foram adulteradas. Eles diferem totalmente em como a chave de assinatura é estruturada.
| Propriedade | HS256 | RS256 |
|---|---|---|
| Nome completo | HMAC com SHA-256 | Assinatura RSA com SHA-256 |
| Tipo de chave | Um segredo compartilhado (simétrica) | Par de chaves privada/pública (assimétrica) |
| Quem pode assinar | Qualquer um com o segredo | Apenas o detentor da chave privada |
| Quem pode verificar | Qualquer um com o segredo | Qualquer um com a chave pública |
| Tamanho do token | Assinatura menor | Assinatura maior |
| Velocidade | Muito rápido | Mais lento para assinar, rápido para verificar |
| Melhor para | Serviço único confiável | Muitos verificadores, terceiros |
Dica chave: com HS256, o verificador e o signatário usam a mesma chave, então a capacidade de verificação e a capacidade de falsificação são inseparáveis. Com RS256, elas são separadas. Esse único fato orienta quase todas as decisões de arquitetura abaixo.
Como o HS256 Funciona (Simétrico, Segredo Compartilhado)#
HS256 significa HMAC usando SHA-256. HMAC é um hash com chave: você alimenta o cabeçalho do token mais o payload e uma string secreta, e ele produz uma assinatura fixa. Para verificar, o serviço receptor executa o mesmo HMAC com o mesmo segredo e verifica se as assinaturas coincidem.
Como a assinatura e a verificação usam um único segredo idêntico, não existe o conceito de lado "público". Qualquer um que possa verificar um token também pode criar um válido. Isso é aceitável quando um único serviço emite tokens e os verifica por conta própria.
Uma configuração típica de HS256 em Node se parece com isso:
import jwt from "jsonwebtoken";
// Assinar
const token = jwt.sign({ sub: "user_123", role: "admin" }, SHARED_SECRET, {
algorithm: "HS256",
expiresIn: "15m",
});
// Verificar (mesmo segredo)
const claims = jwt.verify(token, SHARED_SECRET, { algorithms: ["HS256"] });
O segredo deve ser uma string longa e aleatória (pelo menos 32 bytes para SHA-256). Um segredo fraco ou adivinhável é a forma mais comum de comprometer implantações HS256, pois um invasor que recupere o segredo pode assinar qualquer coisa.
Quando o HS256 é a escolha certa#
- Um monólito único ou um serviço de backend assina e verifica seus próprios tokens.
- Uma conexão interna entre serviços onde você controla totalmente ambas as pontas e pode rotacionar um segredo compartilhado com segurança.
- Você quer o menor token possível e a assinatura mais rápida, sem necessidade de expor a verificação a terceiros.
Como o RS256 Funciona (Assimétrico, Par de Chaves)#
O RS256 é uma assinatura RSA usando SHA-256. Você gera um par de chaves: uma chave privada que assina e uma chave pública que verifica. A chave privada nunca sai do seu servidor de autenticação. A chave pública pode ser publicada abertamente, pois quem a possui pode verificar tokens, mas nunca criá-los.
Essa separação é o ponto principal. Você pode distribuir a chave pública para uma dúzia de microsserviços, um aplicativo móvel ou um parceiro externo, e nenhum deles conseguirá forjar um token, mesmo que a cópia da chave vaze.
import jwt from "jsonwebtoken";
// Assinar com a chave privada (apenas servidor de autenticação)
const token = jwt.sign({ sub: "user_123", role: "admin" }, PRIVATE_KEY, {
algorithm: "RS256",
expiresIn: "15m",
});
// Verificar com a chave pública (qualquer serviço)
const claims = jwt.verify(token, PUBLIC_KEY, { algorithms: ["RS256"] });
A maioria dos grandes provedores de identidade (Auth0, AWS Cognito, Okta, Google e outros que usam OpenID Connect) emite tokens RS256 e publica suas chaves públicas em um endpoint JWKS (uma URL .well-known/jwks.json). Seus serviços buscam a chave pública lá e verificam localmente, sem nunca contatar o servidor de autenticação por requisição.
Aviso: O RS256 só protege você se mantiver a chave privada em segredo e verificar com a chave pública. Um número surpreendente de bugs vem de configurar acidentalmente um serviço para "verificar" com a chave privada, ou lidar incorretamente com formatos de chave. Em caso de dúvida, inspecione o cabeçalho do token para confirmar se o
algé o esperado.
Quando o RS256 é a escolha certa#
- Microsserviços: muitos serviços precisam verificar tokens, mas apenas um deve emiti-los.
- Verificação por terceiros: um parceiro ou aplicativo cliente deve validar seus tokens sem poder criá-los.
- Você usa um provedor de identidade externo ou OpenID Connect, onde RS256 com JWKS é o padrão.
- Você quer rotacionar chaves de assinatura sem redistribuir um segredo para cada verificador (publique uma nova chave pública, retire a antiga).
ES256 e a Família Mais Ampla de Algoritmos#
HS256 e RS256 são os dois que você encontrará com mais frequência, mas não são as únicas opções. ES256 (ECDSA usando P-256 e SHA-256) também é assimétrico, como RS256, mas usa criptografia de curva elíptica. Ele oferece o mesmo modelo de chave privada para assinar e chave pública para verificar, com chaves e assinaturas muito menores, mantendo os tokens compactos.
| Algoritmo | Tipo | Observações |
|---|---|---|
| HS256 | Simétrico (HMAC) | Segredo compartilhado, rápido, confiança única |
| RS256 | Assimétrico (RSA) | Padrão amplamente suportado para OIDC, assinaturas maiores |
| ES256 | Assimétrico (ECDSA) | Chaves/assinaturas menores, moderno, suporte de bibliotecas ligeiramente menos universal |
Se você precisa de assinatura assimétrica e se preocupa com o tamanho do token ou desempenho em escala, ES256 vale a pena considerar. Se você precisa de máxima compatibilidade com ferramentas e provedores de identidade existentes, RS256 continua sendo o padrão mais seguro. A lógica de decisão entre ES256 e RS256 é a mesma que entre RS256 e HS256, acrescida de uma verificação de compatibilidade com suas bibliotecas.
A Regra de Decisão: Quem Verifica Seus Tokens?#
Esta é a parte que a maioria dos artigos ignora. Esqueça velocidade e tamanho da chave por um momento e responda a uma pergunta: quantas partes distintas verificam seus tokens, e você confia que todas elas também podem assinar?
Use HS256 se todo verificador também for um signatário confiável#
Se a única coisa que verifica seus tokens é o mesmo serviço (ou um pequeno conjunto de serviços internos totalmente confiáveis) que os emite, o modelo de segredo compartilhado é mais simples e rápido. Não há problema de distribuição de chaves porque há um segredo e você controla todos os lugares onde ele está. Um monólito clássico com um único backend é o caso típico para HS256.
Use RS256 (ou ES256) no momento em que a verificação se espalhar#
Assim que um token precisar ser verificado por algo que você não quer que seja capaz de assinar, você precisa de chaves assimétricas. Exemplos:
- Um frontend ou cliente móvel verificando a validade de um token.
- Uma frota de microsserviços, onde comprometer qualquer verificador não deve permitir que um invasor forje tokens para todo o sistema.
- Um consumidor de API externo ou parceiro que deve confiar nos tokens que você emite.
- Qualquer fluxo OpenID Connect / OAuth com um provedor de identidade externo.
A regra em uma frase: se o conjunto de verificadores for maior que o conjunto de partes em que você confia para assinar, use RS256. Com um segredo compartilhado, todo verificador é um potencial falsificador, e esse risco cresce a cada serviço que detém o segredo.
Desempenho: Real, mas Geralmente Não é o Fator Decisivo#
HMAC (HS256) é dramaticamente mais rápido que RSA (RS256) na etapa de assinatura, muitas vezes por uma ordem de grandeza em benchmarks brutos. A verificação RSA é razoavelmente rápida, mas a assinatura RSA é a operação cara. Portanto, se você assina enormes volumes de tokens em uma única máquina, o HS256 vence em CPU.
Para a maioria dos aplicativos, essa diferença é irrelevante. Você normalmente assina um token uma vez no login e o verifica muitas vezes durante sua curta vida útil. A verificação com RS256 é rápida o suficiente para que o custo por requisição seja insignificante em comparação com uma consulta ao banco de dados ou um salto de rede. Escolha seu algoritmo com base no modelo de confiança primeiro, e só deixe o desempenho desempatar se você estiver assinando em escala extrema.
Dica: o tamanho do token é uma preocupação mais prática que a CPU. As assinaturas RS256 são maiores, o que infla cada requisição que carrega o token em um cabeçalho. Se você tem restrições de largura de banda e precisa de chaves assimétricas, o ES256 produz tokens visivelmente menores que o RS256.
O Erro que Quebra Ambos: Confiar no Cabeçalho alg#
Independentemente do algoritmo escolhido, o erro de configuração mais perigoso é deixar o próprio token decidir como será verificado. Um JWT carrega um campo alg em seu cabeçalho, e um código de verificação ingênuo lê esse campo e verifica de acordo. Atacantes exploram isso de duas maneiras conhecidas.
Primeiro, o truque alg: none: um atacante define o algoritmo como none, remove a assinatura, e algumas bibliotecas aceitam felizmente o token não assinado como válido. Segundo, o ataque de confusão RS256 para HS256: um servidor configurado para RS256 publica sua chave pública, um atacante altera o cabeçalho para HS256 e assina um token falsificado usando essa chave pública como se fosse um segredo HMAC. Se o servidor então verificar HS256 com a chave pública que conhece, o token falsificado passa.
A correção é a mesma em ambos os casos e é uma linha de intenção: fixe o algoritmo aceito no verificador. Nunca deixe o token escolher.
// Bom: o servidor dita o algoritmo, o token não
jwt.verify(token, PUBLIC_KEY, { algorithms: ["RS256"] });
Sempre passe uma lista explícita de algoritmos permitidos para sua chamada de verificação e certifique-se de que ela não inclua none. Não misture HS256 e RS256 no mesmo caminho de verificação, pois essa ambiguidade é exatamente o que o ataque de confusão precisa. Se você quiser entender por que apenas decodificar um token não diz nada sobre se ele é genuíno, nosso guia sobre decodificar versus verificar um JWT explica a diferença que pega muitos desenvolvedores.
Quando estiver depurando um token em qualquer algoritmo, cole-o em nosso decodificador JWT gratuito para ler o cabeçalho e confirmar o valor de alg, expiração e claims antes de confiar nele. Ver o cabeçalho real é a maneira mais rápida de detectar um algoritmo adulterado ou incompatível.
Gerenciamento de Chaves: A Diferença Prática no Dia a Dia#
A escolha do algoritmo determina silenciosamente quanto trabalho de gerenciamento de chaves você terá.
Com HS256 você tem um único segredo. É fácil de armazenar, mas rotacioná-lo significa atualizar todos os lugares que o armazenam ao mesmo tempo, e um vazamento em qualquer lugar resulta em comprometimento total. Mantenha-o em um gerenciador de segredos, nunca no controle de versão, e trate qualquer serviço que o armazene como parte do seu núcleo confiável.
Com RS256 você gerencia um par de chaves. A rotação é mais suave: publique uma nova chave pública (geralmente via um endpoint JWKS com um id de chave), comece a assinar com a nova chave privada e retire a chave antiga quando os tokens pendentes expirarem. Os verificadores captam a nova chave pública automaticamente. A desvantagem é mais complexidade inicial, por isso um único serviço pequeno raramente precisa disso.
Para uma visão mais ampla sobre manipulação segura de tokens, incluindo armazenamento, expiração e o que verificar em cada validação, veja nosso guia sobre decodificador JWT e segurança de tokens.
HS256 vs RS256: A Conclusão Final#
A decisão entre HS256 e RS256 não é realmente sobre a força criptográfica, já que ambos são seguros quando configurados corretamente. Trata-se de limites de confiança. Use HS256 quando um único serviço confiável assina e verifica seus próprios tokens e você busca simplicidade e velocidade. Recorra ao RS256 (ou ES256 para tokens menores) assim que mais partes precisarem verificar do que você confia para assinar, o que descreve quase toda configuração de microsserviços, dispositivos móveis, terceiros e OpenID Connect.
Seja qual for sua escolha, fixe o algoritmo no verificador com uma lista de permissões explícita, nunca aceite none e nunca verifique tokens de um algoritmo com a chave de outro. Quando algo parecer estranho, decodifique o token e leia seu cabeçalho para saber exatamente com o que está lidando.
Perguntas Frequentes#
O RS256 é mais seguro que o HS256? Não inerentemente. Ambos são criptograficamente sólidos quando configurados corretamente. O RS256 é mais seguro para sistemas distribuídos porque a chave pública de verificação não pode ser usada para forjar tokens, então vazá-la para vários verificadores tem baixo risco. O HS256 concentra todo o poder em um segredo compartilhado, o que é aceitável para um único serviço confiável, mas mais arriscado quanto mais lugares detêm o segredo.
Posso migrar do HS256 para o RS256 depois? Sim, mas planeje uma janela de transição. Você gerará um par de chaves, começará a assinar novos tokens com a chave privada RS256 e atualizará os verificadores para aceitar RS256. Evite configurar um serviço para aceitar ambos os algoritmos ao mesmo tempo, pois essa ambiguidade possibilita o ataque de confusão de algoritmo. Migre de forma limpa e desative a verificação HS256 após a expiração dos tokens antigos.
Qual algoritmo os provedores de identidade como Auth0 e Cognito usam?
A maioria dos grandes provedores de identidade usa RS256 como padrão e publica suas chaves públicas em um endpoint JWKS (uma URL .well-known/jwks.json). Seus serviços buscam a chave pública e verificam os tokens localmente. É por isso que o RS256 é o padrão prático para qualquer integração OpenID Connect ou OAuth com um provedor externo.
Por que o RS256 é mais lento que o HS256? A assinatura RSA é matematicamente mais pesada que a operação HMAC usada pelo HS256, então a assinatura é visivelmente mais lenta, muitas vezes por uma ordem de grandeza em benchmarks brutos. A verificação é rápida para ambos. Para a maioria dos aplicativos, essa diferença não importa, pois você verifica com muito mais frequência do que assina, e o custo da verificação é pequeno comparado ao tempo de rede e banco de dados.
O que é o ataque de confusão de algoritmo?
É uma exploração onde um servidor que espera RS256 é enganado para verificar um token HS256 usando sua própria chave pública como segredo HMAC. Como a chave pública é, por design, conhecida por atacantes, eles podem forjar um token válido. A correção é fixar o algoritmo aceito no verificador com uma lista de permissões e nunca deixar o cabeçalho alg do token decidir. Você pode confirmar o algoritmo declarado de um token com um decodificador JWT gratuito durante a depuração.
Devo usar ES256 em vez de RS256? Considere ES256 quando precisar de assinatura assimétrica, mas quiser tokens e chaves menores, o que ajuda na largura de banda e em clientes móveis. Ele usa o mesmo modelo de assinatura privada e verificação pública do RS256. A principal ressalva é o suporte ligeiramente menos universal de bibliotecas e provedores, então verifique se sua pilha lida com ES256 antes de se comprometer.
