Pare de Usar JWTs

Artigo original ↗ Discussão no Hacker News ↗

Escopo do debate

  • A maioria dos participantes distingue dois casos de uso principais:
    • Sessões de usuário baseadas no navegador.
    • Tokens de serviço para serviço / backend.
  • Consenso suave geral: JWTs muitas vezes são uma escolha ruim para sessões de navegador, mas podem ser bons ou até ideais para cenários de backend e federação.

JWTs para sessões baseadas no navegador

  • Críticos dizem que JWTs adicionam complexidade em relação a IDs de sessão opacos simples em cookies HttpOnly, sem benefício real se o mesmo servidor emite e valida os tokens.
  • Principais pontos problemáticos levantados:
    • Revogação e logout difíceis/complicados, especialmente logout por dispositivo.
    • Repetibilidade e tokens de longa duração.
    • Tendência de colocar dados sensíveis ou mutáveis dentro dos tokens, criando problemas de invalidação de cache e de segurança.
  • Vários argumentam: se você já precisa de um datastore (para usuários, permissões), basta armazenar o estado da sessão ali e evitar criptografia para sessões.

Propriedades de segurança e armadilhas de implementação

  • Problemas históricos: alg=none, downgrade/confusão de algoritmo, bibliotecas aceitando chaves públicas como segredos HMAC, defaults ruins.
  • Alguns argumentam que esses eram bugs de biblioteca e em grande parte já foram corrigidos; outros dizem que eles vêm de uma especificação que incentiva armadilhas e complexidade.
  • Discordância sobre o quão “inseguro” o JWT é hoje:
    • Um lado: “JWT é bom se você restringir algoritmos e usar boas libs.”
    • Outro lado: “A especificação incentiva uso incorreto; CVEs continuam aparecendo; existem designs mais seguros.”

Revogação, autenticação “stateless” e logout

  • Tensão central: JWTs são vendidos como “stateless”, mas logout seguro e tratamento de comprometimento exigem estado:
    • Listas de revogação / denylists.
    • Carimbos de tempo por usuário de “não válido antes de”.
    • Esquemas de rotação de chaves.
  • Alguns argumentam que, uma vez que você adiciona esse estado, perdeu a principal vantagem em relação às sessões clássicas.
  • Outros respondem que listas de revogação são muito menores do que stores completos de sessão e mais fáceis de replicar globalmente.

Cookies, armazenamento e XSS/CSRF

  • Forte apoio a cookies HttpOnly, Secure, SameSite para sessões de navegador.
  • Muitos alertam contra armazenar JWTs em localStorage devido à exfiltração por XSS; alguns minimizam isso se você “não permite JS não confiável”, outros dizem que isso é irrealista.
  • Observação de que HttpOnly impede o roubo do token, mas não o uso indevido impulsionado por XSS.

Alternativas e ecossistema mais amplo

  • Alternativas mencionadas: tokens opacos aleatórios, cookies assinados, PASETO, macaroons, padrões SAML/OIDC, esquemas customizados.
  • Alguns elogiam os designs de PASETO/macaroon por serem mais resistentes a uso incorreto, mas observam ecossistema e adoção limitados.
  • Vários veem o enquadramento “pare de usar JWTs” como exagerado ou caça-cliques; preferem “use JWTs de forma restrita e cuidadosa.”