HS256 vs RS256: Qual Algoritmo JWT Usar

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.