Todos os dias, milhões de pedidos a APIs em Portugal e no resto do mundo passam por uma decisão que a maioria dos programadores toma sem pensar duas vezes: usar JSON Web Tokens (JWT) ou sessões geridas pelo servidor. A escolha parece técnica e menor, mas define como uma aplicação lida com segurança, custos de infraestrutura e velocidade de resposta. Em 2025 e 2026, uma série de vulnerabilidades documentadas em bibliotecas JWT populares voltou a colocar a questão em cima da mesa: o token que promete eliminar o estado do servidor também elimina a forma mais simples de o revogar.

Este artigo compara JWT e sessões lado a lado, com dados de preços reais de 2026, falhas de segurança documentadas com CVE atribuído, benchmarks publicados de latência do Redis e exemplos de empresas que usam cada abordagem. O objetivo é simples: ajudar a escolher a autenticação certa para o projeto certo, sem promessas vazias.

Para equipas em Portugal e no resto da União Europeia, a decisão tem ainda uma camada extra de peso. O RGPD exige que as organizações consigam demonstrar controlo sobre os dados pessoais que processam, incluindo quem acedeu a uma conta e quando esse acesso foi revogado. Um modelo de autenticação que dificulta a revogação imediata não é apenas um risco técnico, é também um risco de conformidade que pode acabar numa auditoria.

O que é JWT e como funciona na prática

Um JSON Web Token é uma cadeia de texto com três partes separadas por pontos: cabeçalho, payload e assinatura, cada uma codificada em Base64URL. O formato está definido na RFC 7519 e não mudou desde a sua publicação, o que o tornou um padrão estável para autenticação distribuída. O cabeçalho indica o algoritmo de assinatura (normalmente HS256, RS256 ou ES256), o payload guarda os dados do utilizador (claims como sub, exp, aud) e a assinatura garante que ninguém alterou o conteúdo pelo caminho.

A ideia central é stateless: o servidor não guarda nada sobre a sessão do utilizador. Basta verificar a assinatura do token recebido e confiar nos dados que ele carrega. Isto elimina a necessidade de consultar uma base de dados ou uma cache em cada pedido, o que torna o JWT particularmente popular em arquiteturas de microserviços, onde vários serviços independentes precisam de validar a identidade do mesmo utilizador sem partilhar uma base de dados central.

// Exemplo de estrutura de um JWT (decodificado)
{
  "alg": "RS256",
  "typ": "JWT"
}
.
{
  "sub": "utilizador_48213",
  "aud": "api.exemplo.pt",
  "exp": 1798000000,
  "iat": 1797996400
}
.
[assinatura RSA de 256 bits]

Este modelo aparece em produtos que qualquer programador conhece. As GitHub Apps, por exemplo, exigem a geração de um JWT assinado com RS256 para se autenticarem junto da API do GitHub antes de pedirem um token de instalação, segundo a documentação oficial do GitHub. O Auth0 também assenta o seu fluxo OpenID Connect em JWT: os ID Tokens são sempre JWT e os Access Tokens costumam sê-lo também. O Postman, por sua vez, inclui um tipo de autorização nativo chamado “JWT Bearer”, prova de como o formato se tornou incontornável em ferramentas de teste de API.

O que são sessões do lado do servidor

As sessões seguem a lógica oposta: com estado. Quando um utilizador faz login, o servidor cria um registo de sessão (normalmente numa base de dados ou numa cache em memória como o Redis) e devolve ao browser apenas um identificador aleatório, guardado num cookie. Em cada pedido seguinte, o servidor recebe esse identificador, procura a sessão correspondente e confirma se ainda é válida.

A vantagem imediata é o controlo. Se uma conta for comprometida, basta apagar o registo da sessão no servidor e o utilizador perde o acesso de imediato, em qualquer dispositivo. Não há espera pela expiração de um token nem necessidade de listas negras. Frameworks maduros como o Laravel assumem este modelo por omissão: a documentação oficial descreve serviços de autenticação e sessão que gerem automaticamente o cookie e os dados guardados no servidor. O Django segue o mesmo caminho, com o seu sistema de autenticação assente na framework de sessões nativa, e o Django Ninja (a camada de API do Django) oferece uma classe SessionAuth que reutiliza essa mesma infraestrutura.

O custo desta segurança é a dependência de infraestrutura partilhada. Se a aplicação corre em vários servidores, todos precisam de acesso à mesma fonte de sessões, normalmente um Redis centralizado. Isso introduz uma chamada de rede em cada pedido autenticado e um ponto único que precisa de alta disponibilidade.

JWT vs sessões: tabela comparativa completa

A tabela seguinte resume as catorze diferenças técnicas mais relevantes entre os dois modelos, com base nas especificações oficiais de cada tecnologia e nos dados de preços recolhidos em 2026.

CaracterísticaJWTSessões do servidor
Modelo de estadoSem estado (stateless)Com estado (stateful)
Onde os dados residemDentro do próprio token, no clienteNuma base de dados ou Redis no servidor
Revogação imediataDifícil, exige listas negrasImediata, basta apagar a sessão
Escalabilidade horizontalNativa, sem partilha de estadoExige armazenamento partilhado
Latência de validação (Redis local)Sem chamada de rede~0,17 a 0,5 ms por pedido
Tamanho típico200 a 800 bytesCookie de poucos bytes (só o ID)
Uso mais comumAPIs, microserviços, apps móveisAplicações web monolíticas, painéis internos
Algoritmos de assinaturaHS256, RS256, ES256Não aplicável (usa segredo de sessão)
Norma técnicaRFC 7519Não normalizada, varia por framework
Dependência de infraestruturaNenhuma para validarRedis ou base de dados obrigatórios
Suporte cross-domain e mobileExcelenteLimitado por regras de cookies same-site
Risco principal documentadoalg=none, confusão de algoritmo, fuga de chaveFixação de sessão, roubo de cookie, CSRF
ExpiraçãoDefinida na claim exp, fixa no momento da emissãoTTL configurável no servidor a qualquer momento
Custo de arranquePerto de zero (auto-alojado)A partir de 0€ (Redis com nível gratuito)

Vulnerabilidades reais de JWT documentadas em 2025 e 2026

A promessa de segurança do JWT depende inteiramente de uma verificação: a assinatura. Quando essa verificação falha, a consequência é sempre a mesma, autenticação completamente contornada. O ataque mais antigo e ainda mais persistente chama-se alg=none. Consiste em alterar o cabeçalho do token para indicar que não há algoritmo de assinatura, esperando que a biblioteca do servidor aceite o token como válido sem verificar nada.

Este problema continuou a aparecer em código de produção em 2025 e 2026, muito depois de ser considerado “resolvido” pela comunidade. Quatro casos documentados mostram a dimensão real do risco:

  • CVE-2025-59685: o Kazaar 1.25.12 permitia forjar JWT com alg=none, contornando por completo a autenticação e a autorização.
  • CVE-2025-59934: o Formbricks (alternativa open source ao Qualtrics) tinha um bypass na verificação de assinatura JWT que permitia a um atacante repor a palavra-passe de qualquer conta, segundo a base de dados de vulnerabilidades da SentinelOne.
  • GHSA-88q6-jcjg-hvmw: a biblioteca jose-swift devolvia sempre true na verificação de tokens com alg=none, sem qualquer validação criptográfica, permitindo a um atacante não autenticado personificar qualquer utilizador.
  • GHSA-28pv-f4g7-364j: a popular biblioteca Python python-jose, em versões até à 3.3.0, aceitava e descodificava tokens com alg=none sem verificação, o que permitia criar claims arbitrárias como is_admin=true e escalar privilégios, conforme documentado no GitHub Advisory Database.

Há ainda um segundo padrão de ataque, a confusão de algoritmo, descrito em detalhe pela PortSwigger Web Security Academy. Funciona quando um servidor aceita tanto assinaturas simétricas (HS256) como assimétricas (RS256) para o mesmo endpoint. Um atacante que consiga obter a chave pública RS256, muitas vezes publicada sem problemas, usa-a como se fosse o segredo HMAC e assina um token falso que o servidor aceita como legítimo. A correção recomendada pelo OWASP JSON Web Token Cheat Sheet é direta: nunca confiar no campo alg do cabeçalho do token para escolher o algoritmo de verificação. O servidor deve impor uma lista fixa de algoritmos aceites, definida no seu próprio código.

Segurança das sessões: riscos diferentes, não ausentes

As sessões não estão livres de falhas, apenas trocam uma categoria de risco por outra. O ataque clássico é a fixação de sessão: um atacante força a vítima a usar um identificador de sessão já conhecido antes do login, e depois usa esse mesmo identificador para aceder à conta depois de autenticada. A defesa é simples e bem conhecida, regenerar o ID de sessão sempre que o nível de privilégio muda, sobretudo após o login.

O segundo risco relevante é o roubo do próprio cookie de sessão, seja por XSS (script malicioso a ler o cookie) ou por interceção de rede sem HTTPS. A mitigação passa por três configurações de cookie que deveriam ser padrão em qualquer aplicação: HttpOnly para impedir leitura via JavaScript, Secure para forçar transmissão apenas por HTTPS e SameSite=Strict ou Lax para reduzir o risco de CSRF. Nenhuma destas proteções existe no mundo JWT porque o token, ao contrário do cookie de sessão, é frequentemente manipulado diretamente por código JavaScript no cliente, o que na prática aumenta a superfície de exposição a XSS.

Um ponto que poucas equipas consideram: o Redis, empresa por trás da tecnologia de cache mais usada para guardar sessões, publicou um artigo próprio a argumentar precisamente o contrário do que se poderia esperar, que JWT são arriscados para sessões de utilizador e que um Redis bem configurado resolve o problema de latência que motivou a adoção de JWT em primeiro lugar. É um argumento interessado, mas tecnicamente sólido.

Desempenho e benchmarks: o que os números realmente mostram

A justificação mais comum para escolher JWT é o desempenho: sem chamada de rede, a validação é instantânea. É verdade, mas a diferença prática depende muito da configuração do Redis e da distância de rede até ele.

Três fontes independentes de benchmark ajudam a quantificar o custo real de uma consulta a sessões:

  • A documentação oficial do Redis regista 140.587,66 pedidos por segundo com 100% das respostas abaixo de 1 milissegundo num teste padrão de leitura.
  • Um benchmark independente publicado nos Arm Learning Paths mediu 149.700,61 pedidos por segundo, com latência média de 0,170 ms, p95 de 0,183 ms e p99 de 0,191 ms.
  • Um terceiro teste, publicado no blog da OneUptime em março de 2026, obteve 287.356,32 pedidos GET por segundo, com latência média de 0,341 ms e p99 de 0,575 ms.

Em resumo, um Redis local ou na mesma região bem dimensionado responde em muito menos de 1 milissegundo por consulta de sessão na esmagadora maioria dos casos. O problema aparece quando o Redis não está perto do servidor de aplicação. Um utilizador do StackOverflow que gere um cluster Redis global partilhou que a latência de rede, nesse cenário distribuído, pode subir para 30 a 50 milissegundos por pedido, uma ordem de grandeza acima do que qualquer verificação local de JWT custa.

A conclusão prática é que o JWT ganha claramente em desempenho quando a arquitetura é distribuída globalmente ou serverless, onde manter uma ligação persistente e próxima a um Redis é difícil ou caro. Em arquiteturas monolíticas com Redis na mesma região, a diferença de latência é, na prática, irrelevante para a maioria das aplicações.

Custos reais em 2026: Redis, Auth0, Cognito e Okta

A escolha entre JWT e sessões também tem impacto direto na fatura mensal. Sessões exigem uma camada de armazenamento persistente, tipicamente Redis. JWT costuma ser combinado com um serviço de gestão de identidade que emite e assina os tokens, como Auth0, AWS Cognito ou Okta. Os preços recolhidos em 2026 mostram diferenças relevantes de escala.

ServiçoCategoriaNível gratuitoPreço pago (2026)
AWS ElastiCache for RedisArmazenamento de sessõesSem nível gratuito permanente$0,016/hora no nó cache.t4g.micro (~$11,68/mês)
Upstash RedisArmazenamento de sessões500 mil comandos/mês e 256 MB$0,20 por 100 mil comandos + $0,25/GB
Redis Cloud EssentialsArmazenamento de sessões30 MB grátisDesde $5/mês (250 MB) até $216/mês (12 GB)
Auth0Emissão e gestão de JWTAté 25.000 MAU (B2C)$35/mês (500 MAU) a $240/mês (1.000 MAU, plano Professional)
AWS CognitoEmissão e gestão de JWT10.000 MAU (planos Lite e Essentials)$0,015/MAU no plano Essentials; $0,020/MAU no plano Plus, sem nível gratuito
Okta Workforce IdentityEmissão e gestão de JWTSem nível gratuitoDesde $6/utilizador/mês (Starter) a $17/utilizador/mês (Essentials)

O padrão que emerge destes números é claro. Para uma aplicação pequena, com poucas centenas de utilizadores ativos por mês, sessões guardadas num Redis Cloud Essentials a $5/mês são mais baratas do que qualquer serviço de identidade JWT pago. O cenário inverte-se à escala: uma base de 100.000 utilizadores ativos custa cerca de $1.500/mês no Cognito Essentials (100.000 × $0,015), enquanto o mesmo volume de sessões cabe confortavelmente num plano Redis de poucas dezenas de dólares por mês, desde que a equipa esteja disposta a gerir essa infraestrutura internamente. O JWT auto-alojado, sem serviço de terceiros, tem custo de infraestrutura próximo de zero, mas transfere o custo para o trabalho de engenharia: rotação de chaves, gestão segura de segredos e implementação correta da validação.

Escalabilidade e arquitetura: microserviços vs monólitos

Em arquiteturas de microserviços, cada serviço precisa de confirmar quem é o utilizador sem depender de uma base de dados central partilhada. É exatamente aqui que o JWT resolve um problema real: qualquer serviço com acesso à chave pública de verificação confirma a identidade sem chamar outro sistema. Numa API Gateway com dezenas de serviços a jusante, isto reduz drasticamente o número de saltos de rede por pedido.

Aplicações monolíticas vivem uma realidade diferente. Um único processo de aplicação, com acesso direto e rápido à sua própria base de dados ou cache, não ganha muito ao eliminar essa consulta. Ganha, isso sim, em simplicidade operacional: revogar acesso, invalidar sessões suspeitas ou forçar logout em massa são operações triviais quando o estado vive no servidor. É por isso que frameworks pensados para aplicações monolíticas, como o Laravel e o Django, continuam a assumir sessões como o modelo padrão, mesmo em 2026.

Backends serverless, como AWS Lambda ou Cloudflare Workers, colocam-se num terreno intermédio interessante. Não têm memória persistente entre execuções e cada função pode arrancar numa máquina diferente a cada pedido, o que torna o JWT particularmente atrativo, já que evita depender de uma ligação persistente a um armazenamento de sessões partilhado.

Há ainda um fator de custo de rede que raramente entra nesta conversa: o tamanho do próprio token. Um JWT típico com claims de utilizador, permissões e metadados pesa entre 200 e 800 bytes, contra apenas alguns bytes de um ID de sessão guardado num cookie. Em APIs com milhões de pedidos diários, esse peso extra soma-se ao tráfego de saída de forma mensurável, sobretudo em pedidos com cabeçalhos já grandes por outros motivos (CORS, tracing distribuído, cabeçalhos de cache). Não é motivo para descartar o JWT, mas é uma variável a incluir no cálculo de custos de banda larga em arquiteturas com volume elevado de tráfego.

O papel do API Gateway também muda consoante o modelo escolhido. Com JWT, o gateway consegue validar a assinatura e aplicar regras de autorização sem tocar em nenhum serviço a jusante, o que reduz a carga nos serviços de negócio. Com sessões, o gateway normalmente delega a validação a um serviço de autenticação central, que por sua vez consulta o Redis, criando um salto adicional que a arquitetura precisa de absorver sem se tornar um gargalo.

Conformidade e RGPD: o que muda para empresas portuguesas

O Regulamento Geral sobre a Proteção de Dados não menciona JWT nem sessões diretamente, mas os seus artigos sobre segurança do tratamento (artigo 32.º) e direito ao apagamento (artigo 17.º) têm consequências práticas para a escolha da arquitetura de autenticação. Quando um titular de dados pede a eliminação da conta, ou quando uma empresa deteta uma fuga e precisa de forçar logout imediato de todos os utilizadores afetados, a capacidade de revogar acesso sem demora deixa de ser um extra e passa a ser uma obrigação legal.

Isto não significa que o JWT seja incompatível com o RGPD. Significa que qualquer equipa que opte por tokens sem estado precisa de implementar, desde o início, um mecanismo de revogação rápido, seja por lista negra em Redis, seja por versão de token. Sem essa peça, uma auditoria de proteção de dados pode identificar uma lacuna real: a incapacidade de garantir, em minutos, que um utilizador deixou de ter acesso ao sistema depois de pedir a eliminação da sua conta. Bancos e seguradoras a operar em Portugal, sujeitos também às exigências da DORA (Regulamento de Resiliência Operacional Digital, em vigor desde janeiro de 2025 para o setor financeiro europeu), tendem por isso a preferir sessões ou JWT de vida muito curta combinado com refresh tokens revogáveis, precisamente para satisfazer estes requisitos sem abdicar da escalabilidade.

Empresas mais pequenas, sem departamento jurídico dedicado, tendem a subestimar este ponto até ao dia em que recebem um pedido formal de eliminação de dados ou uma notificação de incidente. Nessa altura, a diferença entre apagar uma linha numa tabela de sessões e ter de esperar pela expiração natural de tokens já distribuídos torna-se muito concreta.

Exemplos reais: quem usa JWT e quem usa sessões

Nada ilustra melhor a divisão entre os dois modelos do que ver onde cada um é realmente usado em produção.

Produtos e frameworks que usam JWT

  • GitHub Apps: exige a geração de um JWT assinado com RS256 para autenticar a app junto da API antes de qualquer pedido de token de instalação.
  • Auth0: os ID Tokens do seu fluxo OpenID Connect são sempre JWT, e os Access Tokens usados para chamar APIs também costumam sê-lo.
  • Postman: inclui um tipo de autorização nativo “JWT Bearer” nas suas ferramentas de teste de API, sinal de quão comum o formato se tornou.
  • NextAuth.js: permite configurar sessão com estratégia JWT (strategy: 'jwt'), guardando o estado da sessão diretamente num token em vez de numa base de dados.
  • Aplicações OAuth 2.0 e OpenID Connect em geral: a maioria dos fornecedores de identidade modernos emite Access Tokens no formato JWT por omissão.

Frameworks que usam sessões do servidor

  • Laravel: a documentação oficial descreve serviços de autenticação assentes em sessão, com gestão automática do cookie de sessão para pedidos vindos de browser.
  • Django: o sistema de autenticação nativo assenta na framework de sessões do próprio Django, guardando o estado de login no servidor.
  • Django Ninja: a camada de API construída sobre o Django oferece uma classe SessionAuth que reaproveita a mesma infraestrutura de sessões do framework base.

Revogação de tokens: o calcanhar de Aquiles do JWT

Este é o ponto onde a maioria das equipas subestima o JWT. Uma vez assinado, um token continua válido até expirar, mesmo que a conta seja eliminada, a palavra-passe alterada ou o dispositivo roubado. Não há botão de “desligar” um único JWT sem infraestrutura adicional.

Existem três estratégias práticas para mitigar este risco, todas com contrapartidas:

  • Tempo de vida curto: access tokens com validade de 5 a 15 minutos limitam a janela de exposição, mas obrigam a um refresh token para renovar sessões longas sem pedir login constante.
  • Lista negra centralizada: guardar tokens revogados numa cache rápida (normalmente Redis) até expirarem naturalmente. Isto reintroduz exatamente a dependência de estado que o JWT tentava eliminar, mas apenas para o caso de revogação, não para todas as validações.
  • Versão de token por utilizador: guardar um número de versão na base de dados do utilizador e incluir esse número como claim no JWT. Ao mudar a versão, todos os tokens antigos tornam-se inválidos de imediato, sem lista negra completa.

O OWASP JSON Web Token Cheat Sheet reforça esta mesma recomendação: tokens de vida curta, combinados com refresh tokens armazenados de forma segura e rotativos a cada uso, reduzem o impacto de um token roubado sem eliminar as vantagens de desempenho do modelo stateless.

Boas práticas OWASP para JWT em 2026

O OWASP Cheat Sheet Series mantém uma lista de recomendações específicas para JWT que continuam válidas em 2026 e que resolvem, na prática, quase todos os CVE mencionados neste artigo:

  • Impor uma lista fixa de algoritmos aceites no servidor, nunca confiar no campo alg declarado pelo próprio token.
  • Rejeitar explicitamente tokens com alg=none, independentemente do que a biblioteca usada faça por omissão.
  • Validar sempre as claims exp, nbf, aud e iss, com tolerância mínima a diferenças de relógio entre servidores.
  • Guardar chaves de assinatura em gestores de segredos dedicados (KMS, Vault), nunca em variáveis de ambiente sem cifra ou em repositórios de código.
  • Preferir algoritmos assimétricos (RS256, ES256) quando o token precisa de ser verificado por múltiplos serviços que não devem partilhar a capacidade de o assinar.
  • Rodar chaves periodicamente e suportar múltiplas chaves ativas em simultâneo através de um identificador kid no cabeçalho do token.

Guia de migração: de sessões para JWT

Migrar uma aplicação existente de sessões para JWT é um dos pedidos mais comuns quando uma equipa decide separar um monólito em microserviços. Feita de forma apressada, esta migração costuma reintroduzir exatamente os problemas de segurança descritos nas secções anteriores, sobretudo a falta de um plano de revogação. Feita com calma, resolve o problema de escalabilidade sem abrir novas vulnerabilidades. Eis um percurso seguro, testado em várias migrações reais:

  1. Escolher o algoritmo de assinatura antes de escrever qualquer código. RS256 ou ES256 para arquiteturas com múltiplos serviços verificadores, HS256 apenas quando existe um único emissor e verificador confiáveis.
  2. Definir a estrutura mínima de claims necessária: sub, exp, iat, aud e um token_version personalizado para permitir revogação por versão.
  3. Implementar um endpoint de emissão de tokens que corra em paralelo com o sistema de sessões existente, sem o desligar ainda.
  4. Adicionar suporte a refresh tokens armazenados de forma segura (cookie HttpOnly ou armazenamento seguro no cliente móvel), com rotação a cada utilização.
  5. Migrar os endpoints de leitura primeiro, mantendo os de escrita sensíveis (alteração de palavra-passe, dados de pagamento) protegidos por sessão até ao fim da migração.
  6. Configurar um período de coexistência em que ambos os mecanismos são aceites, com métricas a medir a adoção do novo fluxo por parte dos clientes.
  7. Implementar a lista negra ou o mecanismo de versão de token antes de desligar as sessões, nunca depois.
  8. Testar explicitamente os cenários de ataque descritos no OWASP Cheat Sheet, incluindo tentativas de alg=none e confusão de algoritmo, antes de considerar a migração concluída.
  9. Desligar o sistema de sessões apenas depois de confirmar, com dados reais de tráfego, que nenhum cliente antigo depende ainda dele.

Casos de uso: quando escolher cada abordagem

A resposta certa depende quase sempre da arquitetura, não de preferência pessoal. Antes de decidir, vale a pena responder a três perguntas simples: o sistema vai crescer para múltiplas regiões ou serviços independentes, existe uma exigência regulatória de revogação imediata, e a equipa tem capacidade para operar infraestrutura adicional como Redis em alta disponibilidade. As respostas a estas três perguntas apontam quase sempre para o mesmo lado da tabela. Estas seis situações cobrem a maioria dos projetos reais:

  • APIs públicas e microserviços distribuídos por várias regiões: JWT, para evitar depender de um armazenamento de sessões partilhado entre regiões geograficamente distantes.
  • Aplicações web monolíticas com painel de administração interno: sessões, pela simplicidade de revogação imediata e menor superfície de exposição a XSS.
  • Apps móveis e SPA que consomem APIs de terceiros: JWT, porque cookies same-site funcionam mal em contextos cross-domain e nativos.
  • Sistemas de banca, saúde ou qualquer setor com exigência de logout imediato em todos os dispositivos: sessões, ou JWT de vida muito curta combinado com refresh tokens revogáveis.
  • Backends serverless em AWS Lambda ou Cloudflare Workers: JWT, para evitar ligações persistentes a um Redis partilhado entre invocações efémeras.
  • Plataformas SaaS B2B com exigência de auditoria e de forçar logout por um administrador: sessões, ou um modelo híbrido com token de versão controlado pela conta empresarial.

Prós e contras: JWT vs sessões lado a lado

JWT

Prós: sem estado, escala horizontalmente sem esforço, ideal para microserviços e apps móveis, sem dependência de infraestrutura para validar, normalizado pela RFC 7519.

Contras: revogação imediata difícil, maior exposição a roubo via XSS quando guardado em localStorage, histórico recorrente de falhas de implementação (alg=none, confusão de algoritmo), payload maior do que um simples ID de sessão.

Sessões

Prós: revogação imediata e centralizada, superfície de ataque menor com cookies HttpOnly e Secure, mais simples de auditar, controlo total sobre o tempo de vida a qualquer momento.

Contras: exige infraestrutura partilhada (Redis ou base de dados), adiciona latência de rede em cada pedido, mais difícil de escalar entre regiões geograficamente distantes, comportamento inconsistente com cookies cross-domain.

Veredito final: qual escolher em 2026

Não existe vencedor universal, e qualquer artigo que prometa isso está a simplificar demais. Os dados recolhidos apontam para uma escolha guiada pela arquitetura, não pela moda. Para microserviços distribuídos, APIs públicas e aplicações móveis, o JWT continua a ser a opção tecnicamente mais adequada, desde que a equipa implemente rigorosamente as recomendações do OWASP e trate a revogação como um problema a resolver desde o primeiro dia, não como um detalhe para depois.

Para aplicações monolíticas, painéis administrativos e qualquer sistema onde a capacidade de desligar uma conta de imediato pesa mais do que a economia de alguns milissegundos por pedido, as sessões continuam a ser a escolha mais segura e mais simples de operar. Os números de preços mostram que, para a maioria das startups pequenas, um Redis Cloud a $5/mês é mais barato do que qualquer serviço de identidade JWT pago, o que também pesa a favor de sessões em fases iniciais de um produto.

Os quatro CVE analisados neste artigo têm uma causa comum: não uma falha do JWT como conceito, mas implementações que confiaram no próprio token para decidir como verificá-lo. Essa lição vale tanto para quem escolhe JWT como para quem decide manter sessões. A segurança está na disciplina de implementação, não apenas na escolha do formato.

Um modelo híbrido, cada vez mais comum em 2026, combina o melhor dos dois mundos: JWT de vida curta (poucos minutos) para autorizar cada pedido, com um refresh token de vida mais longa guardado no servidor, revogável a qualquer momento. Este desenho evita a maior parte da superfície de ataque documentada nos CVE analisados, mantém a velocidade de validação sem consulta a Redis na maioria dos pedidos, e ainda satisfaz as exigências de revogação imediata do RGPD e da DORA. Não é gratuito, exige mais código e mais testes, mas é o caminho que a maioria das equipas mais experientes tem vindo a adotar à medida que os incidentes de 2025 e 2026 tornaram claro que nenhum dos dois modelos, isolado, resolve todos os problemas ao mesmo tempo.

Perguntas frequentes sobre JWT vs sessões

JWT é mais seguro do que sessões?

Não, são modelos com riscos diferentes. JWT sofre mais com falhas de implementação como alg=none e confusão de algoritmo. Sessões sofrem mais com fixação de sessão e roubo de cookie. A segurança de qualquer um dos dois depende de como é implementado, não do formato em si.

Como revogar um JWT antes de expirar?

As três formas mais usadas são reduzir o tempo de vida do token, manter uma lista negra centralizada em Redis até à expiração natural, ou incluir um número de versão no token que é comparado com um valor guardado na base de dados do utilizador.

É possível usar JWT e sessões ao mesmo tempo?

Sim, e é uma prática comum durante migrações. Muitas equipas usam sessões para o painel web administrativo, onde a revogação imediata é crítica, e JWT para a API pública consumida por apps móveis e integrações de terceiros.

Qual o tamanho recomendado para um JWT?

O OWASP recomenda manter o payload o mais pequeno possível, idealmente abaixo de 1 KB, para evitar problemas com limites de cabeçalhos HTTP em alguns servidores e proxies. Tokens com centenas de claims personalizadas costumam ser sinal de um mau desenho da autenticação.

HS256 ou RS256, qual escolher?

HS256 usa uma única chave partilhada entre quem emite e quem verifica o token, mais simples mas arriscado se vários serviços precisarem dessa chave. RS256 usa um par de chaves pública e privada, permitindo que qualquer serviço verifique tokens com a chave pública sem nunca ter acesso à chave privada de assinatura. Para microserviços, RS256 ou ES256 são a escolha mais segura.

Sessões funcionam bem em aplicações móveis?

Funcionam, mas com mais fricção. Apps móveis não têm o conceito de cookie de browser da mesma forma, o que obriga a gerir manualmente o identificador de sessão no armazenamento seguro do dispositivo. É tecnicamente possível, mas o JWT costuma integrar-se de forma mais natural com SDKs móveis modernos.

O que é um refresh token e é preciso com JWT?

Um refresh token é um token de vida longa, guardado de forma segura, usado apenas para pedir um novo access token JWT quando o anterior expira. Não é obrigatório, mas é considerado boa prática por permitir tokens de acesso com vida muito curta sem obrigar o utilizador a fazer login constantemente.

Quanto custa implementar sessões para 100 mil utilizadores?

Com base nos preços de 2026, um plano Redis Cloud Essentials de alguns GB custa entre $45 e $90 por mês, dependendo do volume de sessões simultâneas. Comparado com o custo equivalente num serviço de identidade JWT como o AWS Cognito Essentials, cerca de $1.500/mês para o mesmo volume de utilizadores ativos, sessões auto-geridas tendem a ser mais baratas à escala, desde que a equipa tenha capacidade para operar essa infraestrutura.

JWT ou sessões, qual escolher para uma startup a começar do zero?

Para a maioria das startups em fase inicial, sessões costumam ser a escolha mais pragmática. O custo de arranque é menor, a implementação é mais simples de auditar e a revogação imediata evita dores de cabeça de segurança enquanto o produto ainda está a validar o mercado. A mudança para JWT faz mais sentido quando a equipa começa a dividir o sistema em serviços independentes ou quando surge a necessidade real de servir apps móveis e integrações externas a partir da mesma API.