Google OAuth está quebrado (mais ou menos)

Artigo original ↗ Discussão no Hacker News ↗

Um comportamento recentemente destacado do Google OAuth permite que funcionários criem contas Google separadas usando aliases de email (como [email protected]) que podem persistir fora do controle da empresa, potencialmente preservando o acesso a apps de terceiros como Slack ou Zoom mesmo após o desligamento. Comentários argumentam que isso decorre menos de uma falha na implementação do Google e mais de usos inadequados e generalizados de OAuth/OIDC, especialmente tratar o email como um identificador estável e confiável em vez de usar IDs de sujeito e fluxos de verificação adequados. A discussão também levanta preocupações sobre a complexidade dos padrões modernos de autenticação web e sobre se recompensas de bug bounty como o pagamento de $1.337 do Google realmente incentivam a divulgação responsável.

Valor da recompensa por bug e resposta do Google

  • Muitos veem o pagamento de $1337 como simbólico, dado o impacto potencial, e o comparam desfavoravelmente com recompensas mais altas relatadas para problemas semelhantes em outros lugares.
  • Outros argumentam que é generoso para o que consideram comportamento documentado ou um “footgun”, não uma vulnerabilidade clássica, e se surpreendem por ter sido recompensado de todo.
  • Alguns observam atrasos no pagamento (meses entre a triagem e a recompensa) como algo típico de grandes empresas, mas acham que o problema real é o valor baixo, não o timing.

De quem é a culpa, afinal? Google vs integradores

  • Uma corrente diz que a falha está principalmente em apps de terceiros (Slack, Zoom, etc.) que:
    • Usam a claim de email como identificador principal.
    • Inferem a associação à organização a partir de domínios de email.
  • Outra corrente argumenta que o Google carrega a responsabilidade porque:
    • Aliases com plus-addressing e contas Google não corporativas compartilham o roteamento de email, mas são invisíveis para administradores do Workspace.
    • O Google poderia teoricamente bloquear novas contas pessoais em domínios já reivindicados por clientes do Workspace ou fornecer controles mais fortes.

Núcleo técnico do problema

  • O Google trata user+suffix@domain (e variantes com ponto) como a mesma caixa de entrada que user@domain, mas permite que contas Google separadas sejam criadas com esses endereços.
  • Um funcionário pode pré-registrar uma conta Google não corporativa usando esse alias e, depois, usar “Sign in with Google” para acessar SaaS corporativo mesmo após sua conta oficial ser desprovisionada.
  • O impacto depende de o SaaS confiar apenas na claim de email para autorização; alguns comentaristas enfatizam que isso é explicitamente desencorajado na documentação de OIDC.

Mitigações e boas práticas

  • Padrões recomendados discutidos:
    • Use iss + sub como chave de identidade estável, não email.
    • Nunca conceda privilégios apenas com base no domínio do email.
    • Exija provisionamento explícito ou allowlists para contas corporativas de SaaS.
    • Envie verificação de email independente ou use “magic link” + 2FA; críticos observam desvantagens de UX e risco de phishing.
    • Prefira SAML/SCIM ou IdPs corporativos dedicados para controle B2B.

Debates mais amplos sobre OAuth/OIDC e identidade

  • Vários participantes descrevem a autenticação delegada e OIDC como excessivamente complexos, mal comunicados e propensos a configuração incorreta.
  • Há discordância sobre se o email deve ser tratado como identidade primária:
    • Pró: globalmente compreensível, amplamente usado.
    • Contra: instável, reutilizável, compartilhado e não exclusivo entre IdPs.
  • Alguns veem o incidente como emblemático de um ecossistema bagunçado de autenticação web, e não de um único momento “Google OAuth está quebrado”.