Sessão, JWT e OAuth2
As três formas mais comuns de identificar o usuário a cada pedido, com as trocas de cada uma.
As decisões de autenticação são quatro: onde fica o estado do login, por quanto tempo uma credencial vale, qual fluxo do OAuth2 usar quando houver delegação e se você constrói o login ou usa um provedor pronto.
Sessão ou JWT
| Critério | Sessão no servidor | JWT |
|---|---|---|
| Consulta a cada pedido | Sim, ao armazenamento de sessões | Não; só confere a assinatura |
| Cortar o acesso na hora | Imediato: apaga o registro | Só com lista de revogação ou espera até vencer |
| Vários servidores | Precisam de um armazenamento compartilhado, como Redis | Qualquer servidor com a chave valida |
| Tamanho no pedido | Pequeno (um identificador) | Maior, e cresce com os dados do token |
| Dados do usuário | Atualizados a cada pedido | Congelados até o token vencer |
| Indicado para | Aplicação web com servidor próprio | APIs consumidas por vários serviços ou clientes |
A vantagem de escala do JWT costuma ser superestimada. Uma consulta ao Redis leva menos de um milissegundo, e quase todo pedido autenticado já vai consultar o banco de qualquer jeito. Em troca, a sessão dá o controle total sobre os logins ativos.
Tempo de vida: token de acesso e token de renovação
Se o JWT for a escolha, o problema da revogação é tratado com dois tokens:
| Token | Duração típica | Onde é usado | Como é cortado |
|---|---|---|---|
| De acesso | 5 a 15 minutos | Em cada pedido à API | Vence sozinho em minutos |
| De renovação (refresh) | Dias ou semanas | Só no endpoint que emite um novo token de acesso | Fica registrado no servidor e pode ser apagado |
O token de acesso, de vida curta, é validado sem consulta. O de renovação é consultado, mas só a cada poucos minutos. Para cortar um acesso, apaga-se o token de renovação, e o usuário perde a sessão quando o token de acesso vencer.
Uma proteção adicional é a rotação: cada uso do token de renovação gera um novo e invalida o anterior. Se um token antigo aparecer de novo, ele foi roubado, e o servidor encerra todos os tokens daquela família.
Fluxos do OAuth2
O OAuth2 define vários fluxos, e só dois são recomendados hoje.
| Fluxo | Para quem | Situação atual |
|---|---|---|
| Código de autorização com PKCE | Aplicações em que um usuário faz login: web, celular, desktop | Recomendado para todos os casos com usuário |
| Credenciais do cliente (client credentials) | Um serviço chamando outro, sem usuário envolvido | Recomendado para comunicação entre sistemas |
| Implícito (implicit) | Aplicações só de navegador | Desaconselhado: entregava o token na URL |
| Senha do usuário (password) | Aplicações que recebem a senha diretamente | Desaconselhado: anula o propósito do OAuth2 |
No fluxo de código de autorização, o usuário é levado ao provedor, faz login lá e volta ao aplicativo com um código de uso único. O aplicativo troca esse código pelos tokens numa chamada direta ao provedor. O PKCE acrescenta um segredo gerado na hora pelo aplicativo, que impede quem interceptar o código de trocá-lo pelos tokens.
Construir ou usar um provedor
| Opção | Exemplos | Vantagens | Custos |
|---|---|---|---|
| Construir no próprio sistema | Biblioteca de autenticação do framework | Controle total, sem custo por usuário | Você responde por senhas, recuperação, segundo fator, bloqueio por tentativas e auditoria |
| Provedor gerenciado | Auth0, Cognito, Entra ID, Firebase Auth, Clerk | Login social, segundo fator e recuperação prontos; equipe especializada em segurança | Custo por usuário ativo; dependência do fornecedor |
| Provedor de código aberto | Keycloak, Authentik, Zitadel | OIDC completo, sem custo por usuário | Você opera, atualiza e protege o servidor |
Construir o login parece simples até a lista de requisitos aparecer: armazenamento seguro de senha, recuperação por e-mail sem enumerar usuários, bloqueio contra tentativas em massa, segundo fator, encerramento de sessões, registro de acessos e login corporativo para clientes empresariais.
Como escolher
| Situação | Escolha |
|---|---|
| Aplicação web com backend próprio e um só domínio | Sessão em cookie HttpOnly |
| Aplicativo móvel e site sobre a mesma API | Provedor OIDC, código de autorização com PKCE, tokens curtos com renovação |
| Microsserviços que precisam saber quem é o usuário | JWT emitido por um ponto central e validado em cada serviço |
| Serviço chamando outro serviço | OAuth2 com credenciais do cliente, ou mTLS |
| Clientes empresariais com login corporativo | Provedor com OIDC e SAML |
| Protótipo ou produto pequeno | Provedor gerenciado; troca-se depois, se for preciso |
Resumo da decisão
- Estado: sessão por padrão; JWT quando vários serviços precisam validar sem consultar.
- Duração: tokens de acesso de minutos, renovação registrada e com rotação.
- Delegação: código de autorização com PKCE para usuários; credenciais do cliente entre sistemas.
- Construção: provedor pronto, salvo motivo forte para fazer em casa.
- Transporte no navegador: cookie
HttpOnly,SecureeSameSite.
O próximo nível mostra a emissão e a validação de um JWT nas cinco linguagens e os cuidados com cookies.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Sessão ou JWT para o meu caso
Preciso decidir entre sessão no servidor e JWT para a autenticação do meu sistema, e quero entender os critérios. Faça estas perguntas, uma por vez, e espere as respostas: - Quem são os clientes: navegador, aplicativo móvel, outros serviços? - O frontend e a API estão no mesmo domínio? - Quantos serviços precisam saber quem é o usuário? - Com que rapidez preciso conseguir cortar o acesso de um usuário? - Já existe Redis ou outro armazenamento compartilhado na infraestrutura? Com as respostas, compare as duas opções para o meu caso: consultas por pedido, revogação, escala, exposição a XSS e CSRF, e complexidade de implementação. Se a recomendação for JWT, explique como montar tokens de acesso curtos com renovação e rotação. Termine com a recomendação, os principais riscos e a configuração dos cookies ou cabeçalhos.
Construir o login ou usar um provedor
Quero decidir se construo a autenticação no meu sistema ou se uso um provedor de identidade. Primeiro, liste tudo o que um login completo de produção precisa ter, além de conferir a senha: armazenamento seguro de senha, recuperação de conta, segundo fator, bloqueio de tentativas, encerramento de sessões, registro de acessos, login social e login corporativo. Para cada item, diga o que costuma dar errado quando é feito às pressas. Depois compare três caminhos: construir com a biblioteca do meu framework, usar um provedor gerenciado (como Auth0, Cognito, Entra ID ou Firebase Auth) e operar um provedor de código aberto (como Keycloak ou Zitadel). Fale de custo, esforço, risco e dependência do fornecedor. Pergunte qual é o meu framework, o tamanho da equipe, o número esperado de usuários e se há clientes empresariais, e recomende um caminho com justificativa.
Escolher o fluxo do OAuth2
Quero aprender a escolher o fluxo correto do OAuth2 para cada tipo de aplicação. Explique os fluxos de código de autorização com PKCE e de credenciais do cliente, e por que os fluxos implícito e de senha foram abandonados. Depois apresente estes cenários, um de cada vez, e pergunte qual fluxo eu usaria e onde os tokens ficariam guardados: 1. Uma aplicação de página única que fala com uma API própria. 2. Um aplicativo móvel nativo. 3. Um serviço que gera relatórios toda madrugada chamando a API de outro serviço. 4. Uma ferramenta de linha de comando em que o usuário faz login. 5. Um backend que precisa chamar a API do Google em nome do usuário. Corrija as minhas respostas e, para os casos de navegador, explique o padrão de ter um backend intermediário que guarda os tokens e entrega só um cookie ao navegador.