JWT

Contém metadados sobre o token: o algoritmo de assinatura (alg) e o tipo de token (typ). É sempre um JSON codificado em Base64url. A escolha do algoritmo declarada aqui afeta diretamente a segurança de todo o token.

{
  "alg": "HS256",
  "typ": "JWT"
}

Contém as afirmações: declarações sobre o usuário e metadados adicionais. Também é um JSON codificado em Base64url. Qualquer pessoa que interceptar o token pode decodificar e ler este conteúdo — os dados do payload NÃO são criptografados, apenas assinados.

{
  "sub": "user_123",
  "role": "admin",
  "exp": 1717200000
}

Uma assinatura criptográfica sobre o cabeçalho e payload codificados. Verificar esta assinatura garante que o token não foi adulterado. A chave secreta (HMAC) ou chave privada (RSA/ECDSA) nunca é incluída no próprio token.

HMACSHA256(
  base64url(header) + "." +
  base64url(payload),
  secret
)

Usa uma chave secreta compartilhada para assinar e verificar. Simples de implementar mas requer que todos os verificadores conheçam o segredo.

Usa uma chave privada para assinar e uma chave pública para verificar. A chave privada nunca sai do servidor de autenticação. Múltiplos serviços podem verificar tokens usando apenas a chave pública, sem precisar compartilhar nenhum segredo.

Como RSA mas com chaves menores e assinatura mais rápida. Fornece segurança equivalente com melhor desempenho.

Sem assinatura. Um token com alg:none não tem garantia de integridade e pode ser falsificado por qualquer pessoa.

Algumas bibliotecas aceitam tokens com alg:none (sem assinatura). Um invasor pode modificar o payload e definir alg como none para falsificar qualquer JWT. Sempre especifique e valide explicitamente o algoritmo permitido na sua biblioteca.

Se uma biblioteca espera verificar RS256 mas aceita HS256, um invasor pode assinar um token usando a chave pública como segredo HMAC. A biblioteca verifica com sucesso sem detectar a fraude. Sempre fixe o algoritmo esperado na configuração da biblioteca.

Um JWT sem afirmação exp, ou código que não verifica exp, permite que tokens sejam usados indefinidamente após o logout ou banimento do usuário. Sempre defina tempos de expiração curtos e valide a afirmação exp em cada requisição.

Os payloads JWT são codificados em Base64, não criptografados. Qualquer pessoa que interceptar um JWT pode decodificar e ler seu conteúdo. Nunca armazene senhas, números de cartão de crédito ou outros segredos nas afirmações JWT.

JWTs assinados com HMAC com segredos curtos ou previsíveis podem ser quebrados por força bruta offline. Um invasor que obtém um JWT pode testar bilhões de chaves por segundo. Use segredos criptograficamente aleatórios de pelo menos 256 bits.

Aceitar JWTs sem verificar a assinatura confia completamente no payload. Este é um bug crítico que permite que qualquer usuário crie afirmações arbitrárias. Sempre verifique a assinatura antes de confiar em qualquer afirmação.

Os JWTs padrão (JWS — JSON Web Signature) são assinados mas NÃO criptografados. O payload é codificado em Base64url, que é trivialmente reversível — qualquer pessoa que obtiver o token pode ler seu conteúdo. O JWE (JSON Web Encryption) oferece criptografia real, mas é muito menos comum na prática.

Os tokens de acesso devem ter vida curta: 5–60 minutos é típico. Tokens de longa duração são perigosos porque não podem ser revogados sem uma lista de bloqueio. Use tokens de atualização — com vida mais longa e armazenados com segurança — para obter novos tokens de acesso sem exigir novo login do usuário.

Cookies HttpOnly são a opção mais segura — são inacessíveis ao JavaScript, prevenindo roubo por XSS. O localStorage é vulnerável a ataques XSS mas evita CSRF. Armazenar em memória (variável JavaScript) é o mais seguro de todos, mas o token não sobrevive a uma atualização de página. Não existe opção perfeita — cada abordagem envolve trocas entre segurança e usabilidade.

Não sem estado no lado do servidor. A natureza sem estado dos JWTs significa que o servidor não pode invalidá-los diretamente. As soluções práticas incluem: tempos de expiração curtos, uma lista de bloqueio de tokens (Redis), tokens de atualização rotativos, ou migrar para tokens opacos de sessão em operações sensíveis.

Cookies de sessão armazenam um ID de sessão aleatório; o servidor procura os dados da sessão em cada requisição. Os JWTs são autossuficientes — o servidor valida a assinatura sem consulta ao banco de dados. Os JWTs escalam melhor em múltiplos servidores, mas não podem ser revogados sem infraestrutura adicional.

O mínimo: sub (ID do usuário), exp (expiração) e iat (emitido em). Adicione iss (emissor) para configurações com múltiplos serviços. Mantenha os payloads pequenos — os JWTs são enviados com cada requisição. Não inclua dados sensíveis nem objetos de perfil volumosos.

RS256 (assimétrico) é melhor para a maioria dos sistemas de produção porque apenas o servidor de autenticação precisa da chave privada. Múltiplos serviços podem verificar tokens usando a chave pública sem compartilhar nenhum segredo. HS256 é mais simples de configurar, mas exige que todos os verificadores conheçam o segredo compartilhado — o que aumenta a superfície de ataque.

PKCE (Proof Key for Code Exchange) é uma extensão do fluxo de código de autorização OAuth2 que previne ataques de interceptação de código. É obrigatório para clientes públicos (SPAs, aplicativos móveis) que não podem armazenar com segurança um segredo de cliente.