JSON Web Token (JWT)

Da História aos Conceitos de Segurança

1. História e Motivação

O Problema: Sessões no Servidor

• Estado (Stateful): Tradicionalmente, o estado da sessão do usuário era armazenado no servidor.
• Escalabilidade: Em arquiteturas de microsserviços ou com balanceamento de carga, compartilhar o estado da sessão entre servidores se torna um desafio complexo.
• Acoplamento: O servidor de autenticação ficava fortemente acoplado à aplicação.

A Solução: Tokens sem Estado (Stateless)

O JWT (JSON Web Token) surge como um padrão aberto (RFC 7519) para resolver esse problema, permitindo a criação de tokens de acesso que carregam as informações do usuário de forma segura e auto-contida.

2. Conceitos Fundamentais

O que é um JWT?

Um JSON Web Token (JWT) é uma forma compacta e segura para transmitir informações entre partes como um objeto JSON. A informação é verificada e confiável porque é assinada digitalmente.

Analogia: Pense em um JWT como um crachá de acesso. Ele contém informações sobre quem você é e o que você pode acessar, e possui uma assinatura que garante sua autenticidade.

3. A Estrutura de um JWT

Um JWT é composto por três partes, separadas por pontos (.):

Header.Payload.Signature

Exemplo:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Estrutura: Header (Cabeçalho)

O cabeçalho geralmente consiste em duas partes:

• typ (Type): O tipo do token, que é JWT.
• alg (Algorithm): O algoritmo de assinatura usado, como HS256 (HMAC com SHA-256) ou RS256 (RSA).

O Header é codificado em Base64Url.

JSON Original:

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

Codificado: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Estrutura: Payload (Carga Útil)

O payload contém as claims (declarações). Claims são declarações sobre uma entidade (normalmente, o usuário) e dados adicionais.

O Payload também é codificado em Base64Url.

JSON Original:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

Codificado: eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

4. Claims: A Informação do Token

Existem três tipos de claims:

• Registered Claims (Registradas): Um conjunto de claims predefinidas e recomendadas.

  • iss (Issuer): Emissor do token.
  • sub (Subject): O "assunto" do token (geralmente o ID do usuário).
  • aud (Audience): Destinatário do token.
  • exp (Expiration Time): Timestamp de quando o token expira.
  • iat (Issued At): Timestamp de quando o token foi criado.

• Public Claims (Públicas): Claims personalizadas, mas com nomes que evitam colisões (ex: usando uma URI).

• Private Claims (Privadas): Claims personalizadas usadas entre partes que concordam em seu uso.

Estrutura: Signature (Assinatura)

A assinatura é usada para verificar a integridade do token. Ela garante que o conteúdo do Header e do Payload não foi alterado.

É criada usando a seguinte fórmula:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  seu-segredo-super-secreto
)

A assinatura impede que alguém modifique o token (ex: trocando "admin": false por "admin": true).

5. Assinaturas e Algoritmos

A segurança do JWT reside na sua assinatura. Os dois algoritmos mais comuns são:

• HMAC (HS256)

  • Simétrico: Usa uma única chave secreta para criar e verificar a assinatura.
  • Simples e rápido.
  • O segredo deve ser compartilhado e mantido seguro entre o emissor e quem for validar o token.

• RSA (RS256)

  • Assimétrico: Usa um par de chaves: uma chave privada para assinar e uma chave pública para verificar.
  • Mais seguro: A chave privada nunca sai do servidor de autenticação. A chave pública pode ser distribuída livremente.
  • Ideal para cenários onde a validação é feita por um serviço diferente do emissor.

6. Fluxo de Autenticação com JWT

1. Login: O usuário envia suas credenciais (ex: email e senha) para o servidor de autenticação.

2. Verificação e Geração: O servidor valida as credenciais. Se estiverem corretas, ele cria um JWT (Header + Payload) e o assina com a chave secreta (HMAC) ou privada (RSA).

3. Envio ao Cliente: O servidor retorna o JWT para o cliente (navegador, aplicativo móvel).

4. Armazenamento: O cliente armazena o JWT de forma segura (geralmente em localStorage, sessionStorage ou Cookies).

5. Requisições Autenticadas: Para cada requisição a uma rota protegida, o cliente envia o JWT no cabeçalho Authorization.

   Authorization: Bearer <token>
   

6. Validação no Servidor: O servidor da API recebe a requisição, extrai o token e verifica a assinatura. Se a assinatura for válida e o token não tiver expirado (exp), a requisição é autorizada.

Diagrama do Fluxo de Autenticação

1. Usuário faz login com credenciais.
2. Servidor de Auth valida e retorna um JWT.
3. Cliente armazena o JWT.
4. Cliente envia o JWT no Header Authorization para acessar recursos.
5. API Server valida a assinatura do JWT.
6. Se válido, API Server retorna o recurso protegido.

7. Segurança: Boas Práticas

• Use um Segredo Forte: Para HMAC, use uma chave secreta longa e complexa. Não a coloque no código-fonte!
• Sempre Valide o Algoritmo: No backend, force a validação usando o algoritmo esperado (ex: HS256). Não confie no valor alg do Header recebido para evitar ataques de "alg: none".
• Defina um Tempo de Expiração Curto (exp): Tokens de acesso devem ter uma vida curta (minutos). Use Refresh Tokens para obter novos tokens de acesso sem pedir login novamente.
• Não Armazene Dados Sensíveis no Payload: O payload é codificado, não criptografado. Qualquer um pode ler seu conteúdo.
• Transmita Apenas por HTTPS: Para evitar que o token seja interceptado (Man-in-the-Middle).

Resumo e Conclusão

• JWT é Stateless: Ideal para microsserviços e aplicações modernas.
• Estrutura Tripla: Header, Payload e Signature.
• Payload (Claims): Carrega as informações do usuário.
• Signature: Garante a autenticidade e integridade, não a confidencialidade.
• Segurança é Crucial: Use algoritmos fortes, segredos seguros, HTTPS e defina expiração.

O JWT é uma ferramenta poderosa e flexível para autenticação e autorização, mas seu poder vem com a responsabilidade de uma implementação segura.

Perguntas?

Bora fazer um sistema de autenticação!