MÓDULO 0 — Fundamentos de HTTP e Web: Tópico 0.2 — Cookies, Sessões e Autenticação

Como vimos no tópico anterior, o HTTP é um protocolo stateless (sem estado). Isso significa que, nativamente, o servidor não lembra de quem fez a requisição anterior. Para criar sistemas onde usuários mantêm o login ativo ou mantêm um carrinho de compras, precisamos de mecanismos de gerenciamento de estado.

1. Cookies HTTP e Atributos de Segurança

Um Cookie é um pequeno pedaço de dado que o servidor envia para o navegador. O navegador o armazena localmente e o envia de volta em todas as requisições futuras para o mesmo domínio.

O servidor define um cookie utilizando o cabeçalho de resposta Set-Cookie:

HTTP/1.1 200 OK
Set-Cookie: session_id=abc123xyz; Secure; HttpOnly; SameSite=Strict

Flags e Atributos de Proteção

Para proteger os cookies de ataques como Cross-Site Scripting (XSS) e Cross-Site Request Forgery (CSRF), utilizamos três atributos fundamentais:

• HttpOnly: Impede que o JavaScript (via document.cookie) acesse o cookie no navegador. Protege contra o roubo de sessão via vulnerabilidades XSS.
• Secure: Garante que o cookie só será transmitido em conexões criptografadas (HTTPS), prevenindo a interceptação de tráfego em rede (sniffing de HTTP em texto claro).
• SameSite: Controla se o cookie é enviado em requisições feitas a partir de sites de terceiros (cross-site):
• - Strict: O cookie nunca é enviado em requisições de origem cruzada. Proporciona a maior proteção contra CSRF.
• - Lax (Padrão na maioria dos navegadores): O cookie é retido em chamadas cruzadas de subrecursos (ex: requisições POST ou imagens), mas é enviado quando o usuário navega diretamente para o site através de um link (GET).
• - None: O cookie é enviado em qualquer contexto de origem cruzada (requer obrigatoriamente a flag Secure).

2. Session ID vs JWT: Como o Servidor Identifica o Usuário?

Existem duas abordagens principais para manter um usuário autenticado:

Autenticação Baseada em Sessão (Stateful)

• Envio de Credenciais: O usuário envia credenciais via POST /login.
• Criação da Sessão: O servidor valida as credenciais, cria um objeto de sessão na sua memória (ou banco de dados / Redis) e gera uma chave aleatória e imprevisível chamada Session ID.
• Resposta com Cookie: O servidor responde gravando essa chave em um cookie (Set-Cookie: session_id=xyz).
• Envio Automático: Nas requisições posteriores, o navegador envia o cookie automaticamente.
• Identificação no Servidor: O servidor lê o session_id, faz uma busca no banco/memória para encontrar qual usuário está associado àquela chave e autoriza a requisição.

Autenticação Baseada em Tokens / JWT (Stateless)

• Envio de Credenciais: O usuário envia credenciais via POST /login.
• Geração do Token: O servidor valida as credenciais e assina digitalmente um objeto JSON chamado JWT (JSON Web Token) usando uma chave secreta.
• Envio do Token: O servidor responde enviando o token no corpo da resposta ou em um cookie.
• Armazenamento e Envio: O cliente armazena o token e o envia manualmente em cada requisição (normalmente no cabeçalho Authorization: Bearer <token>).
• Validação Matemática: O servidor não consulta banco nem memória. Ele apenas valida a assinatura matemática do JWT usando sua chave secreta. Se a assinatura for válida e o token não estiver expirado, ele confia nas informações contidas dentro do próprio token (ex: ID do usuário).

3. Anatomia do JSON Web Token (JWT)

Um JWT é composto por três partes separadas por pontos (.): Header.Payload.Signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFuYSBTaWx2YSIsImlhdCI6MTUxNjIzOTAyMn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

• 1. Header (Cabeçalho): Define o algoritmo de assinatura usado (ex: HS256 ou RS256) e o tipo de token (JWT).
• 2. Payload (Carga Útil): Contém as alegações (claims), como ID do usuário, nome, permissões e data de expiração (exp). Atenção: Os dados no Payload são apenas codificados em Base64URL, NÃO são criptografados por padrão! Qualquer um pode lê-los.
• 3. Signature (Assinatura): Garante a integridade do token. Gerada a partir da combinação do Header, Payload e da chave secreta do servidor:

HMACSHA256(Base64(Header) + "." + Base64(Payload), chave_secreta)

4. Exemplos Práticos de Cabeçalhos HTTP

Cenário 1: Login e Acesso usando Session ID

1. Requisição de Login (POST /login)

POST /login HTTP/1.1
Host: meu-sistema.com
Content-Type: application/x-www-form-urlencoded

username=carlos&password=SenhaForte123!

2. Resposta do Servidor (definindo a sessão)

HTTP/1.1 200 OK
Set-Cookie: session_id=9a8b7c6d5e4f3a2b; Secure; HttpOnly; SameSite=Strict
Content-Type: application/json

{"status": "sucesso", "mensagem": "Logado com sucesso"}

3. Requisições Seguintes (enviadas automaticamente pelo navegador)

GET /painel/perfil HTTP/1.1
Host: meu-sistema.com
Cookie: session_id=9a8b7c6d5e4f3a2b
User-Agent: Mozilla/5.0

Cenário 2: Login e Acesso usando JWT

1. Requisição de Login (POST /api/auth)

POST /api/auth HTTP/1.1
Host: api.meu-sistema.com
Content-Type: application/json

{
  "email": "carlos@exemplo.com",
  "password": "SenhaForte123!"
}

2. Resposta do Servidor (retornando o JWT)

HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_token": "eyJhbGciOiJIUzI1Ni...SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c",
  "token_type": "Bearer",
  "expires_in": 3600
}

3. Requisições Seguintes (enviadas no cabeçalho Authorization)

GET /api/v1/relatorios HTTP/1.1
Host: api.meu-sistema.com
Authorization: Bearer eyJhbGciOiJIUzI1Ni...SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Accept: application/json