Pare de usar JSON Web Tokens para sessões de utilizador

Artigo original ↗ Discussão no Hacker News ↗

Os desenvolvedores estão a debater se os JSON Web Tokens (JWTs) são apropriados para gerir sessões de utilizador em aplicações web, especialmente single-page applications. Muitos argumentam que o problema não é o JWT em si; os riscos reais vêm de os armazenar em locais acessíveis por JavaScript, como `localStorage`, de proteção fraca contra XSS e da dificuldade de revogar tokens, levando alguns a preferir sessões tradicionais do lado do servidor ou JWTs armazenados em cookies `HttpOnly`, `SameSite`. Outros observam que os JWTs ainda fazem sentido em sistemas distribuídos e APIs, mas sublinham que devem ser usados com modelos de ameaça claros, tempos de vida curtos e implementação cuidadosa para evitar armadilhas de segurança comuns.

Âmbito do Debate

  • Muitos argumentam que o artigo é realmente sobre XSS e escolhas de armazenamento, e não sobre os JWTs em si.
  • Esclarecimento repetido: JWT é apenas um formato de token; pode ser usado com cookies ou outro armazenamento, e não é inerentemente oposto a “sessões baseadas em cookies”.

Onde Armazenar o Estado da Sessão

  • Corrente forte: armazenar identificadores de sessão/JWTs em cookies HttpOnly, Secure, SameSite.
    • Protege contra roubo direto do token por XSS.
    • Evita o trabalho manual de configurar cabeçalhos; o browser envia os cookies automaticamente.
  • Crítica ao localStorage / armazenamento acessível por JavaScript:
    • Facilmente exfiltrado por XSS; especialmente problemático para refresh tokens de longa duração.
    • Algumas frameworks (Firebase, Cognito) usam por padrão local/IndexedDB e não podem usar HttpOnly.
  • Visão minoritária: localStorage é “aceitável” porque XSS significa “fim de jogo” de qualquer forma, e atacantes ainda podem abusar de cookies através de pedidos no browser.

CSRF, SameSite e Cookies

  • Recomendação: definir SameSite em cookies sensíveis.
    • Lax é muitas vezes visto como suficiente para proteção contra CSRF; Strict pode quebrar o comportamento de estar autenticado na primeira página.
  • Há alguma confusão sobre como posts de formulários cross-site interagem com cookies; SameSite é apontado como o controlo.

Modelo de Ameaça de XSS

  • Um lado: se JavaScript pode ser injetado, o atacante já pode agir como o utilizador (enviar pedidos), então cookie vs localStorage importa pouco.
  • O outro lado: HttpOnly ainda limita de forma significativa o dano ao impedir a exfiltração e reutilização do token a partir de outro dispositivo; defesas em camadas importam.

Design de JWT e Revogação

  • Vantagens dos JWTs citadas:
    • Validação sem estado; bom para APIs, sistemas distribuídos e microserviços.
    • Serviços a jusante podem autorizar via JWT sem consultar uma base de dados de autenticação a cada vez.
  • Grande desvantagem: difícil de revogar / terminar sessão:
    • Padrão típico: access tokens de curta duração + refresh tokens de longa duração, muitas vezes com refresh tokens opacos e verificados na base de dados.
    • Quando se adicionam listas de revogação ou verificações em base de dados, perde-se parte dos benefícios “sem estado”; alguns questionam por que usar JWT nessa altura.
  • Vários recomendam IDs de sessão opacos simples em cookies, convertendo para JWTs apenas internamente em gateways.

Preocupações Legais / UX / Práticas

  • Esclarecimento de que cookies funcionais/de sessão geralmente não requerem banners de consentimento; há confusão em torno da “diretiva de cookies.”
  • Alguns queixam-se de orientação de segurança absolutista (por exemplo, timeouts muito curtos) prejudicar a usabilidade.
  • Outros criticam artigos do tipo “Pare de usar X” que não oferecem alternativas claras, práticas ou nuance.