Na era das arquiteturas distribuídas, a identidade deixou de ser um registro estático em um banco de dados para se tornar um objeto nômade e autônomo. O JSON Web Token (JWT) surgiu como a resposta técnica à necessidade de escalabilidade horizontal, prometendo livrar o backend do gargalo das sessões centralizadas através de um modelo stateless.
Contudo, essa conveniência arquitetônica introduziu uma mudança crítica no perímetro de confiança: ao transferir o estado da sessão do servidor para o cliente, passamos a confiar em artefatos portadores de privilégios que transitam em território hostil. A flexibilidade do JWT é uma faca de dois gumes: quando a implementação ignora as nuances da criptografia e do gerenciamento de chaves, a facilidade de desenvolvimento rapidamente se traduz em vetores de escalada de privilégio e vazamento de dados. Neste artigo, analisaremos a anatomia desse protocolo e as falhas lógicas que tornam o JWT um dos alvos favoritos em operações de segurança ofensiva.
Contexto: O Tradicional ID de sessão
Antes do JWT, o padrão ouro era (e para muitos casos, ainda é) o ID de sessão. O fluxo é simples:
- O usuário se autentica.
- O servidor gera uma string aleatória única (o ID de sessão).
- O servidor armazena essa string em memória, banco de dados ou arquivo, vinculando-a aos dados do usuário.
- O cliente recebe esse ID via Cookie e envia em cada requisição.
Nesse modelo, o estado é mantido no servidor, o ID de sessão é apenas um ponteiro para qual é o objeto referente àquela sessão.
Por que usar JWT?
O modelo de ID de sessão enfrenta um gargalo de escalabilidade horizontal. Se você tem 10 instâncias da sua aplicação, todas precisam consultar a mesma base de sessões (como um banco de dados ou arquivo) para validar o usuário e saber as informações relacionadas à sessão. Isso gera latência e ponto único de falha.
O JWT busca solucionar isso sendo stateless. Em vez de o servidor guardar a sessão, o próprio token carrega todas as informações necessárias (ID do usuário, permissões, role). O servidor não precisa lembrar de você, ele apenas precisa validar a assinatura do que você entregou.
Anatomia de um JWT
Um JWT é composto por três partes separadas por pontos (.), todas codificadas em Base64:
- Header: Define o tipo do token e o algoritmo de assinatura (ex: HS256).
- Payload (Claims): Contém os dados propriamente ditos (ex:
name,admin: true). - Signature: O mecanismo que garante que o Payload e o Header não foram alterados por terceiros.
Nota Crítica: Base64 não é criptografia. Qualquer pessoa que interceptar um JWT pode decodificar o Payload em milissegundos.
Preocupações, Falhas e Limitações
A implementação do JWT é frequentemente acompanhada pela falsa sensação de segurança que o termo “assinatura digital” evoca. No entanto, em segurança ofensiva, o modelo de ameaça dita as regras: se o token trafega por um ambiente que não controlamos totalmente, ele deve ser tratado como se estivesse em território hostil. A suposição de que a validade matemática de uma assinatura garante, por si só, a segurança lógica de uma transação é uma suposição perigosa e a falácia central que abre caminho para explorações. Assim como no TOCTOU, onde a confiança no estado estático de um recurso permite o ataque, no JWT, a confiança cega no conteúdo do token sem considerar o contexto de uso cria janelas críticas de vulnerabilidade. Abaixo, analisamos os cenários onde essa confiança colide com a realidade.
O Dilema da Invalidação
Diferente das sessões em banco de dados, que podem ser deletadas instantaneamente fazendo o logoff forçado do usuário, um JWT é autônomo. Se você emitir um JWT válido por 24 horas, ele será válido por 24 horas, mesmo que você altere a senha do usuário ou o bloqueie no banco.
Uma solução comum para contornar esse problema é criação de blocklist que é propagado para as diferentes instâncias da aplicação e permite “invalidar” um JWT.
Janela de Expiração e Cookie Stealing
Um erro comum é definir o campo de expiração para prazos longos (dias, semanas ou até meses) para “melhorar a UX”. Se um atacante obtiver um token via ataque de XSS, interceptação de rede, ou até malware “chupa-cabra”, o atacante terá acesso total à conta até o token expirar.
JWT em QR Codes
Implementar JWT em QR codes é uma solução eficiente para controle de acesso físico offline. Um exemplo prático é o ticket de estacionamento: o leitor da cancela valida a assinatura do token impresso para liberar o veículo. Entretanto, o ambiente físico traz desafios adicionais em comparação ao tráfego via cookies. A principal preocupação é o ataque de replicação; um atacante pode simplesmente fotografar o QR code para clonar o token e utilizá-lo múltiplas vezes, o que exige mecanismos rigorosos de controle de estado ou expiração curta.
Vazamento de Dados (Assinatura ≠ Criptografia)
Este é talvez o erro mais perigoso de desenvolvedores iniciantes. Ao confundir a garantia de autenticidade (assinatura) com confidencialidade (criptografia), muitos colocam dados sensíveis no Payload, como CPFs, emails ou até segredos de negócio. O JWT (usando JWS) garante que o dado não foi alterado mas ele é legível por qualquer um. Caso precise esconder os dados, seria necessário usar JWE que é consideravelmente mais complexo.
Vulnerabilidade alg: none
No início do JWT, muitos parsers aceitavam o algortimo none. Isso abre uma brecha para que o atacante altere o header para {"alg": "none"}, remover a assinatura do token e o servidor aceitaria o payload modificado como válido. Hoje a maioria das bibliotecas modernas bloqueia isso porém implementações customizadas ainda sofrem com esse bypass clássico
Simetria vs Assimetria
A escolha do algoritmo de assinatura é um ponto crítico que define a arquitetura de confiança do sistema, sendo classificada essencialmente entre modelos simétricos e assimétricos. No paradigma simétrico, exemplificado pelo algoritmo HS256, a mesma chave secreta é utilizada tanto para a geração da assinatura quanto para a sua validação, o que obriga a distribuição desse segredo por todas as instâncias que precisem verificar o token. Essa prática expande perigosamente a superfície de ataque, pois o comprometimento de qualquer instância que armazene a chave resulta na perda total da integridade da autoridade emissora.
Em contrapartida, o modelo assimétrico, representado por algoritmos como RS256 ou ES256, opera com um par de chaves distinto onde uma é utilizada exclusivamente para assinar e a outra apenas para verificar. A vantagem fundamental dessa abordagem reside na redução drástica do risco de vazamento da chave de assinatura. Como a vasta maioria das instâncias e microsserviços da aplicação requer apenas a chave pública para validar a autenticidade do JWT, a chave privada pode ser mantida em um ambiente isolado, robusto e de acesso extremamente restrito. Assim, mesmo em um cenário de invasão de um serviço verificador, o atacante é incapaz de forjar novos tokens, uma vez que o segredo necessário para a criação da assinatura nunca deixou o ambiente seguro do servidor de autenticação. Essa distinção é um exercício prático de modelagem de ameaça, garantindo que a defesa seja proporcional ao risco e ao adversário em questão.
A Fragilidade do Segredo (Cracking Offline)
Diferente dos IDs de sessão tradicionais, onde um atacante precisaria testar combinações contra o servidor (gerando logs e batendo em rate limits), o JWT permite o offline brute-forcing. Como o token contém o cabeçalho, o payload e a assinatura resultante, o atacante possui todos os elementos necessários para tentar adivinhar a chave secreta em seu próprio hardware.
Se uma aplicação utiliza o algoritmo HS256 com uma chave fraca ou previsível, um atacante pode utilizar ferramentas como Hashcat ou John the Ripper para realizar ataques de dicionário.
O Poder do Cracking de GPU
Em um cenário de auditoria, não é raro encontrar chaves que parecem complexas mas estão em listas de vazamentos comuns. Utilizando o Hashcat (modo 16500), um hardware moderno de consumo pode testar milhões de combinações por segundo.
# Exemplo de comando no Hashcat para crackear um JWT
hashcat -m 16500 jwt_token.txt dictionary.txtUma vez que a chave secreta é descoberta, o comprometimento é total: o atacante pode forjar tokens para qualquer usuário, alterar permissões de admin: false para true e assinar o token como se fosse o servidor legítimo. Isso reforça por que a entropia da chave é tão vital quanto o algoritmo escolhido; de nada adianta usar criptografia de ponta se a “senha” da criptografia for trivial.
Gestão de Chaves e Single Sign-On
Em arquiteturas modernas de Single Sign-On (SSO), como a implementada pelo Google, a decisão pelo uso de chaves assimétricas transcende a conveniência técnica e torna-se um pilar de resiliência. Nesse cenário, o provedor de identidade atua como a autoridade central, utilizando sua chave privada — protegida em ambientes de hardware de segurança (HSMs) — para assinar o JWT. A aplicação cliente, por sua vez, jamais tem contato com o segredo de assinatura, limitando-se a consumir chaves públicas disponibilizadas via endpoints como o JWKS (JSON Web Key Set). Essa separação de privilégios garante que, mesmo diante de um comprometimento total do servidor da sua aplicação, o atacante seja incapaz de comprometer a cadeia de identidade global. O invasor encontrará apenas um certificado de validação, permanecendo impossibilitado de forjar identidades ou escalar privilégios de forma autônoma, pois a “raiz da verdade” permanece isolada e inacessível fora do domínio do provedor de identidade.
O Perigo no Mundo Físico: Bilhetagem e Controle de Acesso
A vulnerabilidade do JWT atinge um patamar crítico quando o token é transportado para o mundo físico, como em sistemas de bilhetagem ou controle de acesso que operam via QR Code em catracas e leitores muitas vezes offline. O erro fatal em tais implementações é o uso de chaves simétricas armazenadas localmente no hardware de validação. Se um atacante obtém acesso físico ao dispositivo leitor — seja por furto ou em um cenário de laboratório — ele pode realizar técnicas de hardware hacking para extrair a chave secreta diretamente da memória ou do armazenamento volátil do aparelho. Uma vez que o segredo de assinatura é extraído, a segurança do sistema colapsa: o atacante agora possui a capacidade de gerar infinitos JWTs “autênticos” e válidos, contornando qualquer lógica de segurança de software. Nesse contexto, a integridade do sistema não depende mais da robustez do algoritmo, mas sim da resistência física do hardware, transformando o dispositivo de validação no elo mais fraco de uma cadeia que deveria ser protegida por criptografia de ponta a ponta.
Conclusão
O uso de JSON Web Tokens não é uma “bala de prata”, mas sim uma troca (trade-off) consciente entre escalabilidade stateless e controle granular de estado. Como vimos, a mesma característica que permite ao JWT brilhar em arquiteturas de microsserviços e sistemas distribuídos — a sua autonomia — é a que introduz vetores de ataque complexos quando a implementação negligencia o modelo de ameaça.
A migração do modelo tradicional de sessões para o JWT exige uma mudança de mentalidade: a confiança deixa de residir em uma base de dados centralizada e passa a residir na matemática da assinatura e na integridade da gestão de chaves.
