JWT vs Sessions: stateless ou estado no servidor?
JWTs são tokens autocontidos verificados por assinatura sem consulta ao servidor; sessions armazenam estado no servidor e o referenciam com um cookie.
A auth com JWT coloca claims em um token assinado que o servidor valida de forma stateless, o que escala horizontalmente sem armazenamento de sessão compartilhado mas torna a revogação imediata difícil. A auth com sessions mantém o estado em um store (memória, Redis, DB) referenciado por um cookie de session ID, dando revogação fácil e cookies pequenos ao custo de uma consulta e armazenamento compartilhado. JWT favorece statelessness; sessions favorecem controle e revogação.
| JWT | Sessions | |
|---|---|---|
| Estado | Stateless (no token) | Store no servidor |
| Revogação | Difícil (até expirar) | Fácil (apagar a session) |
| Escala | Sem store compartilhado | Precisa de store compartilhado |
| Tamanho do payload | Token maior | Cookie pequeno |
| Melhor para | APIs, microsserviços | Apps web, logout fácil |
Tradeoffs
JWTs se adequam a APIs stateless e chamadas serviço-a-serviço onde você quer evitar um session store central; mantenha-os de curta duração e combine com refresh tokens para mitigar a revogação fraca. Sessions se adequam a apps web clássicos que precisam de logout instantâneo, invalidação fácil e cookies pequenos, aceitando um store compartilhado como Redis. Muitos sistemas usam sessions para apps de navegador e JWTs para APIs.
Em CI
Testes de integração de auth devem exercitar os caminhos de expiração e revogação. Armazene as chaves de assinatura/segredos no secret store do CI. Em runners gerenciados, mascare segredos e evite embutir chaves nas imagens.
O veredito
APIs stateless e microsserviços onde evitar um session store importa: JWT (curta duração, com refresh). Apps web que precisam de logout instantâneo e revogação simples: sessions no servidor. Um híbrido - sessions para navegadores, JWTs para APIs - é comum e evita a principal fraqueza de cada modelo.