OAuth Account Takeover em SaaS B2B: 5 padrões que dominam em 2026

Account Takeover (ATO) via OAuth é uma das classes de bug mais lucrativas em programas de bug bounty internacionais — e uma das menos cobertas em pentest tradicional brasileiro. Scanner não detecta. Checklist OWASP não cobre direito. E o vetor é difícil porque depende de entender o protocolo, não só de rodar payload em campo de input.

Este artigo explica os 5 caminhos de ATO via OAuth que mais aparecem em programas reais em 2025–2026, com exemplos reais (anonimizados) e o que time defensivo precisa fazer para bloquear.

O que é OAuth, em uma frase

OAuth 2.0 é um protocolo de autorização que permite que uma aplicação (cliente) obtenha acesso aos recursos de um usuário em outra aplicação (provedor) sem que o usuário precise compartilhar suas credenciais com a primeira. É como entregar a chave do seu carro ao manobrista do hotel: você dá acesso limitado, sem passar suas chaves de casa.

OIDC (OpenID Connect) é uma camada em cima de OAuth 2.0 que adiciona autenticação (saber quem é o usuário), não só autorização.

Por que OAuth é vetor frequente de ATO

OAuth 2.0 tem um diagrama com pelo menos 5 atores e 8 trocas de mensagens. A especificação tem 80+ páginas. Na prática:

• Desenvolvedor lê documentação superficial e implementa ~70% certo
• Os 30% errados moram nos detalhes que parecem opcionais
• Esses detalhes são onde mora o exploit

Vamos aos 5 caminhos.

1. State confusion — o clássico que ainda funciona

O parâmetro state serve para vincular a request inicial de autorização à resposta. Sem state, ou com state previsível, o atacante consegue forjar a resposta para a vítima.

Cenário típico:

1. Atacante clica em “Conectar com Google” na conta dele
2. Captura a URL de callback gerada pelo provedor (com code)
3. Manda essa URL para a vítima como link em phishing
4. Vítima clica, está logada no app — o callback é processado contra a sessão da vítima
5. Conta do atacante fica vinculada ao usuário da vítima — ou vice-versa

Padrão recorrente em pentest:SaaS B2B onde fluxo de “conectar com Google” não valida state corretamente — qualquer usuário pode ser forçado a vincular conta atacante via link compartilhado em Slack ou email. Esse vetor aparece com frequência em programas de bug bounty públicos com pagamento entre US$ 2.000 e US$ 15.000.

Como bloquear: state criptograficamente aleatório (mínimo 128 bits), vinculado à sessão, validado no callback antes de processar o code.

2. Redirect URI fuzz — o moderno e ainda subestimado

O OAuth provider valida o redirect_uri contra uma lista pré-aprovada. Se a validação for fraca, o atacante consegue redirecionar para domínio dele com o code da vítima.

Bypass comuns:

• Validação por prefixo: cadastrou https://app.com, atacante usa https://app.com.evil.com
• Validação por sufixo: cadastrou app.com/callback, atacante usa https://evil.com/callback?x=app.com/callback
• Validação que aceita parâmetros de query: https://app.com/callback?next=https://evil.com (open redirect interno)
• Path traversal: cadastrou https://app.com/oauth/callback, atacante usa https://app.com/oauth/callback/../../external?url=evil.com
• Subdomain takeover: cadastrou subdomínio que está com CNAME apontando para SaaS abandonado

Como bloquear: validação por igualdade exata (full string match). Sem wildcard, sem prefixo, sem sufixo. Lista de redirect_uri pré-cadastrada e fechada.

3. Code injection / code leakage

O code retornado pelo provider deve ser de uso único e curto prazo. Mas existem padrões onde ele vaza:

• Code aparece em Referer header se a página de callback tiver imagens externas
• Code é logado em servidor (proxy reverso, CDN, APM)
• Code é guardado em localStorage e fica acessível a XSS
• Code é enviado por GET em endpoint que aceita CORS aberto

Padrão recorrente em pentest: aplicações que logam callbacks OAuth completos em ferramentas de observabilidade (DataDog, Splunk, Sentry, New Relic) — qualquer engenheiro com acesso a esses logs pode coletar códigos de autorização de usuários e, sem PKCE obrigatório, trocá-los por access tokens válidos. É um achado clássico em auditoria de fintechs e SaaS B2B em produção.

Como bloquear:

• PKCE obrigatório (mesmo para clientes confidenciais)
• Code com TTL curto (5 minutos máx, 30 segundos ideal)
• Sanitização de logs (filtrar campo code)
• Header Referrer-Policy: no-referrer na página de callback

4. PKCE bypass

PKCE (Proof Key for Code Exchange) foi introduzido para proteger clientes públicos (mobile, SPA) de interceptação de code. Em 2026, é obrigatório também para clientes confidenciais — em teoria.

Bypass comuns:

• Server aceita request sem code_verifier (PKCE optional)
• Server aceita code_challenge_method=plain (PKCE inútil)
• Server aceita code_verifier com hash que não bate (validação ausente)
• Server permite reutilizar code_challenge entre requests

Como bloquear: rejeitar todas as 4 condições acima explicitamente. PKCE com S256, obrigatório, validado.

5. Implicit / Hybrid flow ainda existindo em produção

OAuth 2.1 (em draft, vai virar RFC) deprecou implicit flow e hybrid flow com token na URL. Eles são frágeis: token aparece em URL, fica em browser history, em logs, em Referer. Mas em 2026 ainda existem em produção.

Cenário: app legacy com implicit flow. Vítima é redirecionada paraapp.com/#access_token=abc123. Atacante consegue ler:

• Via XSS injectado em app.com
• Via plugin de browser malicioso instalado no perfil da vítima
• Via navigator.share abusado
• Via subframe hijack se a página for embeddável

Como bloquear: migrar para Authorization Code Flow + PKCE. Não use implicit. Não use hybrid com tokens em URL. Se cliente legacy precisa de migração gradual, isolar implicit em domínio separado e monitorar agressivamente.

Bonus: confused deputy quando você é OAuth client

Se sua aplicação consome OAuth de terceiros (login com Google, Microsoft, Facebook), você é cliente OAuth. Você precisa proteger:

• Verificar id_token (nonce, audience, issuer)
• Não confiar em email não verificado vindo do provider
• Vincular conta do provider à conta interna por sub (ID estável), não por email
• Tratar “email já existe” com cuidado: senão um atacante pode tomar conta antiga apenas mudando email no Google

Esse último vetor — account confusion via email não verificado — é hoje um dos exploits mais lucrativos em ATO. Atacante com Google Workspace próprio configura alias para email do alvo, conecta no app, vincula à conta da vítima.

Como o pentest sério ataca tudo isso

A No Vuln usa o OAuth State Fuzzer (ferramenta proprietária) para automatizar:

• State guessing e replay
• Redirect URI fuzz (50+ payloads de bypass)
• PKCE downgrade attacks
• Code reuse attempts
• JKU/X5U injection em ID tokens

E manualmente, pesquisador valida cada caminho com PoC reproduzível, alinha severidade ao impacto de negócio (ATO em conta de admin enterprise = P0; em conta de usuário comum = P1 ou P2 dependendo do dado), e escreve recomendação específica de correção.

Conclusão

OAuth ATO em 2026 é exploit de detalhe. Não cai no scanner. Não cai em revisão de checklist. Cai em pesquisador que entende o protocolo e tem ferramenta para fuzzar os 50+ caminhos de bypass.

Se sua aplicação tem OAuth (e em 2026 quase toda tem), pentest superficial não te protege. Vale buscar consultoria que mencione explicitamente os 5 vetores deste artigo antes de começar.