Sessão, JWT e OAuth2

Autenticação e autorização

Os dois termos andam juntos e respondem perguntas diferentes:

• Autenticação: quem é você? O sistema confere uma prova de identidade, como senha, código ou chave.
• Autorização: o que você pode fazer? Com a identidade conhecida, o sistema decide se a ação é permitida.

Este tópico trata da primeira pergunta e de como a resposta acompanha cada pedido. A segunda tem um tópico próprio na trilha.

O problema: o HTTP esquece

O usuário digita e-mail e senha uma vez. O sistema confere e responde que está tudo certo. No pedido seguinte, o servidor já não sabe quem é aquela pessoa, porque o HTTP não guarda memória entre pedidos.

Toda forma de login na web resolve o mesmo problema: depois de conferir a senha, o servidor entrega ao cliente uma credencial, e o cliente a envia em cada pedido seguinte. As soluções diferem no que essa credencial contém e em onde fica o estado do login.

Sessão: o servidor lembra

Depois do login, o servidor cria um registro de sessão (quem é o usuário, quando entrou, quando expira) e o guarda na memória, no banco ou num Redis. O cliente recebe apenas o identificador desse registro, num cookie:

HTTP/1.1 200 OK
Set-Cookie: sessao=k3J9xQ2mZ8...; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=86400

O navegador devolve o cookie sozinho em cada pedido ao mesmo site:

GET /pedidos HTTP/1.1
Cookie: sessao=k3J9xQ2mZ8...

O servidor procura o identificador no armazenamento e descobre quem é o usuário. O identificador em si não significa nada: é um valor aleatório e longo, impossível de adivinhar.

Como o estado está no servidor, encerrar um login é imediato: apaga-se o registro, e o cookie passa a apontar para o nada.

Token assinado: o cliente carrega a prova

No modelo com token, o servidor monta um documento com os dados do usuário, assina esse documento com uma chave que só ele conhece e o entrega ao cliente. O formato mais usado é o JWT (JSON Web Token): três partes em Base64, separadas por pontos.

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0MiIsImV4cCI6MTc3MzE1MDAwMH0.Xk2...
       cabeçalho                     conteúdo                 assinatura

Decodificado, o conteúdo é um JSON comum:

{
  "sub": "42",
  "papel": "cliente",
  "iss": "https://api.loja.com.br",
  "aud": "loja-web",
  "exp": 1773150000
}

O cliente envia o token no cabeçalho Authorization:

GET /pedidos HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...

O servidor confere a assinatura e a validade e confia no conteúdo, sem consultar banco nenhum. Qualquer servidor que tenha a chave consegue validar o token. Essa é a grande vantagem do modelo.

O preço aparece na hora de cortar um acesso. O token vale até o horário em exp, e o servidor não guarda lista nenhuma para consultar. Se o usuário trocar a senha ou um token vazar, ele continua aceito até vencer, a menos que você crie um mecanismo de revogação, o que traz de volta uma consulta a cada pedido.

Cookie e cabeçalho não são concorrentes

Uma confusão comum é tratar "cookie" e "JWT" como alternativas. Cookie é um meio de transporte; JWT e identificador de sessão são conteúdos.

• Um JWT pode viajar dentro de um cookie.
• Um identificador de sessão pode viajar no cabeçalho Authorization.

O que muda com o transporte é a exposição a ataques:

Um cookie com HttpOnly não pode ser lido por JavaScript nenhum, nem por um script injetado. Por isso, em aplicações web, a recomendação geral é guardar a credencial num cookie HttpOnly, Secure e SameSite, e não no localStorage.

OAuth2 e OpenID Connect: delegar

As duas soluções anteriores resolvem o login no seu próprio sistema. O OAuth2 resolve outro problema: permitir que um aplicativo acesse dados do usuário em outro serviço, sem receber a senha dele.

O exemplo clássico é um aplicativo de agenda que quer ler o seu calendário do Google. Em vez de pedir a sua senha do Google, ele redireciona você ao Google. Você faz login lá e autoriza o acesso ao calendário. O Google devolve ao aplicativo um token de acesso limitado: só leitura, só o calendário, por algumas horas. Você pode revogar essa permissão a qualquer momento, sem trocar a senha.

O OAuth2 sozinho diz o que o aplicativo pode acessar, mas não diz quem o usuário é. O OpenID Connect (OIDC) é uma camada sobre o OAuth2 que acrescenta essa informação, num token de identidade. É o que existe por trás dos botões "Entrar com Google", "Entrar com a Microsoft" e do login corporativo das empresas.

Por que isso importa quando a IA escreve o código

Um assistente gera um login funcional em minutos, quase sempre com JWT e quase sempre com os mesmos pontos fracos:

• O token fica no localStorage, ao alcance de qualquer script injetado na página.
• O token vale por dias, e não existe forma de cortar o acesso de um usuário demitido.
• A validação confere a assinatura, mas não o emissor, o público nem o algoritmo.
• Dados sensíveis vão dentro do token, achando que ele é criptografado.
• O próprio sistema implementa cadastro, senha, recuperação e segundo fator, quando um provedor pronto resolveria com menos risco.

O próximo nível compara as soluções e mostra como escolher entre elas.