Escolhendo um modelo de identidade

Três modelos, cada um visto isoladamente. Coloque-os lado a lado e fica claro o que cada um está otimizando, porque cada um abre mão de algo para conseguir isso.

O que cada um realmente entrega

• Sessões stateful ancoram tudo no servidor. A identidade fica lá, e o controle também, então elas são previsíveis, atualizáveis e revogáveis instantaneamente. Em troca, você tem algo central que precisa escalar e se manter sincronizado, o que fica mais difícil a cada servidor que você adiciona.
• Tokens de portador opacos apontam para o servidor. A identidade ainda mora lá, num pequeno mapeamento de token para usuário em vez de um armazenamento completo de sessões. O servidor fica bem mais leve, mas não totalmente livre, porque ainda existe uma consulta a fazer. Um meio-termo prático.
• JWTs levam a ideia stateless até o fim, colocando toda a identidade dentro do próprio token. Sem consulta, sem armazenamento compartilhado, sem coordenação, sem carga no servidor. Um objeto assinado em que o servidor confia instantaneamente, e uma verdadeira dor de cabeça quando você precisa revogar acesso.
• Identidade delegada transfere a responsabilidade para fora do seu sistema por completo. Você deixa de se preocupar com senhas, mas herda a complexidade de manter uma relação com um provedor que precisa dar certo.

Stateful é para controle. Stateless é para escala. Delegado é para transferir a confiança.

JunoO que cada um realmente entrega Nenhuma dessas opções é a melhor. Cada uma é boa em algo e paga o preço em outro lugar.

O que é meio libertador: a pergunta deixa de ser "qual é a resposta certa" e passa a ser "no que esse app pode se dar ao luxo de ser ruim".

JunoO que cada um realmente entrega Os quatro modelos ficam numa linha, e vale a pena enxergá-los assim. Sessões mantêm tudo no lado do servidor; tokens opacos mantêm um mapeamento enxuto; JWTs não mantêm nada; delegado mantém a questão toda em outro lugar.

Percorrendo essa linha, você troca controle por escala, um passo de cada vez. Nomear em que ponto você está costuma resolver uma discussão de arquitetura mais rápido do que listar funcionalidades.

JunoO que cada um realmente entrega A comparação que a tabela não consegue fazer é a operacional. Sessões precisam de um armazenamento que tem que ficar sempre no ar, então a disponibilidade dele vira a disponibilidade do seu login.

JWTs não precisam de armazenamento, mas precisam de gestão de chaves, rotação e um plano para o dia em que um segredo vazar. Delegado não precisa de nenhum dos dois, mas torna seu uptime parcialmente dependente de um provedor.

Nada disso aparece numa comparação de funcionalidades, e tudo isso aparece num incidente. Vale perguntar, para qualquer modelo que você escolha, como é a falha das três da manhã e quem é chamado para resolver.

Lado a lado

	Stateful	Token opaco	JWT	Delegado
Onde a identidade mora	No servidor	No servidor, de forma enxuta	No token	Com o provedor
Por requisição	Consulta à sessão	Consulta ao token	Verificação de assinatura	Depende do que você emite depois
Armazenamento no servidor	Armazenamento completo de sessões	Mapeamento pequeno	Nenhum	Nenhum
Revogar agora	Sim	Sim	Não	Parcialmente, depende deles
Escala horizontalmente	Precisa de armazenamento compartilhado	Precisa de armazenamento compartilhado	Livremente	Livremente
Você abre mão de	Coordenação	Um pouco de coordenação	Poder mudar de ideia	Controle

JunoLado a lado A linha de revogação é a primeira que você deveria ler. É a diferença que mais pesa e a mais difícil de mudar depois.

Se você precisa tirar alguém do sistema agora mesmo, a resposta é uma consulta em algum lugar. Tudo o mais decorre disso.

JunoLado a lado Repare que tokens opacos e sessões compartilham a mesma coluna na maioria das linhas. Esse é o retrato honesto: tokens opacos são uma versão mais leve da mesma ideia, não uma família diferente.

A verdadeira bifurcação está entre "o servidor consegue consultar" e "o servidor não consegue", e a coluna do JWT é a única do outro lado dessa linha.

JunoLado a lado Nada aqui é fixo para sempre, e migrar é mais fácil numa direção do que na outra. Ir de sessões para tokens é basicamente aditivo: emita tokens em paralelo, migre os clientes, aposente as sessões. Voltar de tokens para sessões significa construir o armazenamento que você tinha deliberadamente evitado e reautenticar todo mundo.

Então, quando a escolha está apertada, o modelo que mantém uma consulta é o erro mais barato. Você sempre pode tirar o estado depois; colocá-lo de volta é a migração que ninguém agenda.

Quando cada um se encaixa

• Stateful brilha quando o servidor precisa continuar no controle: logout instantâneo, atualização de papéis em tempo real, controle rígido sobre o estado do usuário. Estável e previsível, serve bem para dashboards, ferramentas administrativas e qualquer coisa em que controle importa mais do que escala horizontal.
• Stateless brilha quando a arquitetura precisa de espaço para crescer. Numa API, ou em qualquer coisa que escale sem estado de sessão coordenado, deixar o cliente trazer o próprio token elimina esse atrito de imediato. Tokens opacos mantêm a coisa simples; JWTs eliminam a consulta por completo.
• Delegado faz sentido no momento em que você percebe que não quer manter um sistema de senhas de jeito nenhum. Ou quando a velocidade de onboarding importa, ou quando você quer uma base de segurança mais forte do que a que construiria sozinho. Seu app deixa de provar identidade e passa a consumi-la.

E a virada com que vale a pena encerrar: muitas vezes você não escolhe só um. Sistemas reais combinam os modelos, usando identidade delegada para estabelecer quem é a pessoa, uma sessão para o site principal e JWTs para chamadas de API. Cada um resolve uma fatia diferente do problema.

JunoQuando cada um se encaixa Combinar os modelos parece trabalho extra, mas geralmente é menos. Cada modelo cuida da parte em que é bom.

O Google prova quem você é, uma sessão mantém você logado no site, um token te leva através da API. Três trabalhos, três ferramentas.

JunoQuando cada um se encaixa Quando você combina os modelos, anote onde a identidade é estabelecida e onde ela é consumida, porque esse é o diagrama sobre o qual as pessoas discutem sem se entender.

O padrão comum: o provedor autentica, seu back-end emite sua própria sessão ou token, e tudo a partir daí confia no seu, não no do provedor. Continuar passando o token do provedor adiante é o que emaranha as integrações.

JunoQuando cada um se encaixa Um cuidado ao combinar modelos: cada modelo que você adiciona é uma porta de entrada, e elas precisam estar alinhadas. Uma conta acessível tanto por senha quanto por login delegado tem duas forças de autenticação, e um atacante usa a mais fraca.

Aplicar MFA no caminho da senha enquanto um caminho delegado o contorna é a versão disso que acaba indo para produção. O mesmo vale para um fluxo de redefinição de senha que concede uma sessão para uma conta que só fez login pelo Google.

A regra que se sustenta: todo caminho de acesso a uma conta deveria ser tão forte quanto a proteção mais forte dela, ou essa proteção forte é só decoração.

Coloque em prática

Cinco sistemas. Escolha um modelo para cada um e nomeie a propriedade que decide isso.

1. Um dashboard web clássico para a equipe interna. Administradores precisam de logout instantâneo, mudanças de permissão devem valer imediatamente, e segurança importa mais do que escala.
2. Uma API pública que serve um app mobile.
3. Uma arquitetura grande de microsserviços em que uma dezena de serviços precisa saber quem está chamando.
4. Um app de consumo cujo objetivo principal é cadastro rápido, idealmente com Google ou Apple.
5. Um projeto hobby de servidor único.

Compare suas respostas

#	Modelo	A propriedade decisiva
1	Stateful	O servidor continua no controle. Mudar um papel ou deslogar alguém tem efeito na próxima requisição. Para um app de navegador comum, sessões são simples e confiáveis
2	Stateless, qualquer um dos dois tipos	Cada requisição traz um token que o servidor verifica e segue em frente, sem uma pilha crescente de sessões para rastrear conforme o uso aumenta
3	Stateless, especificamente JWTs	Autocontido, então cada serviço verifica por conta própria em vez de todo serviço perguntar a um servidor central a cada chamada
4	Delegado	Nenhuma senha para lidar, e o cadastro mais rápido possível
5	Stateful	A coisa mais simples que funciona. Um servidor, uma tabela de sessões pequena, um cookie. Sem tokens, sem OAuth, nada para operar

Um e cinco chegam à mesma resposta por caminhos opostos, e é isso que é útil aqui. O primeiro escolhe sessões porque controle importa mais; o quinto as escolhe porque nada mais é necessário. Nenhum dos dois é uma decisão de escala, e escala é o que as pessoas costumam presumir que orienta essa escolha.

Para onde isso leva a seguir

Quatro perguntas agora viajam com você para qualquer sistema de login que você encontrar. Onde a identidade realmente mora? Como o servidor sabe que essa pessoa é quem ela diz ser? O que acontece se isso vazar, expirar ou for adulterado? Qual modelo se encaixa nesse app, e por quê?

Esse é o raciocínio, não uma checklist, e é isso que torna um sistema de autenticação desconhecido legível.

A próxima seção muda completamente de assunto. Fundamentos de limitação de taxa deixa de perguntar quem é alguém e passa a perguntar com que frequência essa pessoa tem permissão para pedir algo.