A autenticação moderna: passkeys, OIDC, sessões - a verdadeira lista curta

Um thread popular no HN reacende a questão: como devemos autenticar um aplicativo em 2026? A resposta não é mais "JWT + refresh token". Panorama atualizado.

Em termos simples

Em 2026, a "boa" forma de autenticar um aplicativo web depende de duas questões: (1) você é um app B2C de consumo ou um SaaS B2B? (2) você está disposto a operar seu próprio IdP ou depende de um provedor? Os padrões do meio dos anos 2020 (JWT sem estado + refresh no localStorage) estão obsoletos — por boas razões.

O caso

O tópico do HN retoma a discussão clássica e chega a uma convergência interessante: para a maioria dos apps, a pilha pragmática de 2026 é:

1. Sessão server-side criptografada em cookie HttpOnly + SameSite=Lax para o estado de autenticação. Fim do JWT armazenado no lado do cliente.
2. OIDC (Google/Apple/GitHub) para onboarding sem senha.
3. Passkeys (WebAuthn) para a segunda etapa ou substituição completa da senha. Finalmente adotado em todos os lugares (iOS 17+, Android 13+, todos os navegadores).
4. Rotação curta da sessão server-side (~1h) + refresh longo (~14 dias) via cookie separado.
5. Sem JWT no lado do cliente, a menos que você tenha autenticação stateless multi-tenant real para implementar.

O que mudou estruturalmente são três coisas. Um: o fim do localStorage para tokens sensíveis (XSS = comprometimento total, não há mais debate). Dois: a maturidade das passkeys — a adoção no consumidor superou o limiar crítico nos principais ecossistemas (Google, Apple, Microsoft já implementaram), mesmo que nenhum tenha publicado números recentes detalhados. Três: os provedores de identidade hospedados (Clerk, WorkOS, Auth0) agora oferecem cobertura SSO/SCIM/passkeys pronta para uso que nenhuma equipe com menos de 5 pessoas deveria reimplementar.

Por baixo dos panos

• Cookie de sessão: Secure; HttpOnly; SameSite=Lax; prefixo __Host-. Rotação a cada escalada de privilégio.
• CSRF: SameSite=Lax cobre 95% dos casos; adicionar um token CSRF nas mutações sensíveis ainda é a precaução.
• PKCE obrigatório em todos os fluxos OAuth públicos (SPA, mobile).
• Armadilha comum: tornar a passkey obrigatória em 2FA muito cedo — perda de conta se o usuário tiver apenas um dispositivo.
• Vulnerabilidade atual: extensões de navegador que leem a memória de uma SPA — argumento adicional para não armazenar nada no localStorage.

Então, o que fazer?

Três pontos principais. Um: se você está começando em 2026, use um provedor (Clerk, WorkOS, Stack Auth), a menos que haja uma razão regulatória específica. O tempo de engenharia economizado pode ser direcionado ao produto. Dois: se você tem uma pilha herdada de JWT no localStorage, planeje a migração para cookie de sessão — é um trabalho de segurança prioritário, não cosmético. Três: as passkeys estão prontas; ativá-las como opção agora e torná-las obrigatórias até 2027 no ambiente corporativo. A se observar: a padronização das passkeys entre plataformas (o verdadeiro entrave no B2B).