JWT e OAuth: os sete erros de autenticação que abrem a porta sem quebrar a criptografia
Quase nunca é a criptografia que falha — é como o token é validado, onde é guardado e o que o fluxo OAuth confia. Os sete padrões de autenticação quebrada que mais encontramos, com o que testar e como corrigir.
O ataque não quebra o cadeado — usa a porta dos fundos
Quando uma autenticação com JWT ou OAuth cai num pentest, quase nunca é porque quebramos AES ou RSA. É porque a validação do token tem um buraco, o fluxo confia num parâmetro que o atacante controla, ou o token vive num lugar de onde pode ser roubado. Autenticação quebrada é o item A07 do OWASP Top 10, e é onde uma única falha vira acesso à conta de qualquer usuário.
Abaixo, os sete padrões que mais encontramos — o que são, como testamos e o que corrige.
1. alg: none e variantes
O JWT diz como deve ser verificado no próprio header (alg). Bibliotecas antigas ou mal configuradas aceitam alg: none — token sem assinatura — ou não fixam o algoritmo esperado. Teste: trocar o alg para none, remover a assinatura, ver se o backend aceita. Correção: fixar o algoritmo no servidor (allowlist), nunca ler alg do token para decidir como validar.
2. Confusão RS256 → HS256
O servidor usa RS256 (chave pública/privada). O atacante muda o header para HS256 (simétrico) e assina o token usando a chave pública — que é, por definição, pública — como se fosse o segredo HMAC. Bibliotecas que escolhem o verificador pelo alg do token caem nisso. Correção: verificador estritamente amarrado ao algoritmo esperado.
3. Segredo HMAC fraco ou vazado
HS256 com segredo secret, changeme, o nome da empresa, ou um segredo que vazou num repositório público. Com o segredo, o atacante forja qualquer token — vira admin em uma linha. Teste: ataque de dicionário offline sobre a assinatura. Correção: segredo aleatório de alta entropia, fora do código, rotacionável.
4. Claims não validados
A assinatura confere, mas o backend não valida exp (expiração), aud (audiência) ou iss (emissor). Token expirado continua válido; token emitido para outro serviço é aceito. Teste: reusar token expirado, usar token de outro ambiente/serviço. Correção: validar exp, nbf, aud, iss sempre; rejeitar por padrão.
5. redirect_uri frouxo no OAuth
O coração de muitos account takeovers via SSO. Se o servidor de autorização aceita redirect_uri por prefixo ou permite subdomínios/paths arbitrários, o atacante desvia o code ou o token para um domínio que controla. Variações: open redirect encadeado no fluxo, state ausente (CSRF no login), PKCE não exigido em clientes públicos. Teste: manipular redirect_uri, remover state, interceptar o code. Correção: allowlist exata de redirect_uri, state obrigatório, PKCE em SPA e mobile.
6. Token no lugar errado
JWT em localStorage é lido por qualquer XSS — e aí um único XSS vira roubo de sessão persistente. Token em log, em URL (referer vaza), em cache de CDN. Correção: cookies HttpOnly, Secure, SameSite; nunca token de sessão em localStorage; nunca token em query string.
7. Sem revogação e sessão eterna
JWT é stateless: uma vez emitido, vale até expirar. Se o exp é longo e não há lista de revogação nem refresh token rotacionado, um token roubado funciona por horas ou dias, e trocar a senha não desloga o atacante. Correção: exp curto + refresh token rotacionado e revogável; invalidar sessões na troca de senha e no logout.
Por que scanner não pega
Quase todos esses exigem manipular o token e entender o fluxo — dois contextos, duas contas, um proxy interceptando o handshake OAuth. Um scanner vê um login que funciona e passa adiante. É teste manual, guiado pelo OWASP WSTG (seção de autenticação) e pelas boas práticas de OAuth 2.0 / OIDC.
O que pedir no pentest
Peça cobertura explícita de: manipulação de alg, confusão de algoritmo, força bruta offline do segredo, validação de claims, todo o fluxo OAuth/OIDC (incluindo redirect_uri, state, PKCE), armazenamento do token e ciclo de vida da sessão. E peça o encadeamento até o impacto — "forjei um token de admin" vale mais que "o exp não é validado".
Como a Pentest Machine testa isso
Nos pentests de web e API tratamos autenticação como superfície de primeira classe: manipulação de JWT, fluxos OAuth/OIDC completos, SSO, armazenamento e sessão, com PoC reproduzível para cada falha e o caminho até o account takeover quando existe. Relatório executivo + técnico e reteste inclusos. Se você usa SSO ou emite JWT para clientes, esse é o teste que separa "parece seguro" de "é seguro".