JSON Web Token (JWT): Guia de Autenticação e Segurança

O que é JWT?

JWT (JSON Web Token) é um formato de token compacto e seguro para URL, definido no RFC 7519, usado para troca segura de informações entre partes.

JWT consiste em três partes: Header, Payload e Signature. Essas três partes são separadas por pontos (.): xxxxx.yyyyy.zzzzz

Fornece autenticação stateless. Em vez de armazenar dados de sessão em um banco de dados, o servidor envia o token ao cliente. O cliente envia o token com cada requisição.

Casos de uso: Autenticação API, SSO (Single Sign-On), autenticação entre microserviços, autorização de aplicativos móveis.

Estrutura JWT

Header: Contém tipo de token (JWT) e algoritmo de assinatura (HS256, RS256, ES256). Codificado em Base64URL.

Payload: Contém claims. Registered claims (iss, sub, aud, exp, nbf, iat, jti), public claims e private claims. Codificado em Base64URL.

Signature: O header e payload codificados em Base64URL são unidos por um ponto e assinados com uma chave secreta. HS256 usa HMAC-SHA256, RS256 usa RSA-SHA256.

Exemplo: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Fluxo de uso JWT

1. O usuário envia uma requisição ao endpoint de login com nome de usuário e senha.

2. O servidor verifica as credenciais e cria um JWT. O token é retornado no body da resposta ou cookie.

3. O cliente armazena o token em localStorage ou cookie httpOnly.

4. Em requisições subsequentes, o cliente envia JWT como Bearer token no header Authorization: Authorization: Bearer <token>

5. O servidor valida o token (verificação de assinatura e expiração). Se válido, processa a requisição; se inválido, retorna 401 Unauthorized.

Riscos de segurança

Roubo de token: O token em localStorage pode ser roubado via ataque XSS. Use cookie httpOnly para reduzir o risco XSS.

Tempo de vida do token: Access token de curta duração (15-30 min) + refresh token de longa duração (7-30 dias). Rotacione o refresh token a cada uso.

Confusão de algoritmo: Algoritmo 'none' ou mudança RS256→HS256. Defina o algoritmo como constante no servidor, não o pegue do token.

Dados sensíveis: O payload JWT é codificado em Base64, não criptografado. Não coloque dados sensíveis (senha, cartão de crédito) no payload.

Tamanho do token: JWT é maior que cookie de sessão. Enviado com cada requisição. Mantenha o payload mínimo.

Melhores práticas

Tokens de curta duração: Access token 15-30 minutos, refresh token 7-30 dias. Tokens expirados tornam-se inválidos automaticamente.

Cookie httpOnly + Secure + SameSite: Armazene o token em cookie httpOnly. JavaScript não pode acessar (proteção XSS). Secure (apenas HTTPS). SameSite (proteção CSRF).

Rotação de token: O refresh token é renovado a cada uso. O refresh token antigo torna-se inválido. Limita o acesso do atacante em caso de roubo de token.

Blacklist/revogação: Use blacklist para revogar tokens. Armazene tokens revogados no Redis. Use para logout e incidentes de segurança.

Algoritmo: RS256 (assimétrico) recomendado para produção. Assine com chave privada, verifique com chave pública. HS256 (simétrico) apenas para um único serviço.

Validação: Verifique assinatura, issuer (iss), audience (aud), expiração (exp) em cada requisição. Certifique-se de que todas as verificações passem antes de confiar no token.

JWT vs Autenticação baseada em sessão

JWT: Stateless, escalamento horizontal fácil, ideal para microserviços, tamanho de token grande, difícil de revogar.

Session: Stateful, requer armazenamento do lado do servidor, precisa de sticky session ou shared store para escalamento horizontal, tamanho de token pequeno, fácil de revogar.

Critérios de seleção: Arquitetura de microserviços → JWT. Aplicação monolítica → Session. App móvel → JWT. Alto requisito de segurança → Session + JWT híbrido.

Abordagem híbrida: JWT de curta duração (access token) + session store (refresh token). Combina vantagens de ambos.