Google OAuth está roto (más o menos)
Un comportamiento de Google OAuth destacado recientemente permite a los empleados crear cuentas Google separadas usando alias de correo (como [email protected]) que pueden persistir fuera del control de la empresa, preservando potencialmente el acceso a apps de terceros como Slack o Zoom incluso después de la baja. Los comentaristas sostienen que esto se debe menos a un fallo de la implementación de Google y más al uso generalizado incorrecto de OAuth/OIDC, en especial tratar el correo como un identificador estable y fiable en lugar de usar IDs de sujeto y flujos de verificación adecuados. El intercambio también plantea preocupaciones sobre la complejidad de los estándares modernos de autenticación web y sobre si recompensas de bug bounty como el pago de Google de $1,337 incentivan de forma significativa la divulgación responsable.
Valor del bug bounty y respuesta de Google
- Muchos ven el pago de $1337 como meramente simbólico dada la posible repercusión y lo comparan desfavorablemente con recompensas más altas reportadas para problemas similares en otros sitios.
- Otros sostienen que es generoso para lo que consideran comportamiento documentado o un “footgun”, no una vulnerabilidad clásica, y les sorprende que se haya recompensado en absoluto.
- Algunos señalan los retrasos en los pagos (meses entre la triaje y la recompensa) como algo típico en las grandes empresas, pero creen que el problema real es la cantidad baja, no el tiempo.
¿Quién es realmente el responsable? Google vs integradores
- Un bando dice que el fallo recae principalmente en las apps de terceros (Slack, Zoom, etc.) que:
- Usan el reclamo de correo electrónico como identificador principal.
- Infieren la pertenencia a una organización a partir de los dominios de correo.
- Otro bando argumenta que Google asume la responsabilidad porque:
- Los alias con plus y las cuentas Google no organizacionales comparten el enrutamiento del correo, pero son invisibles para los administradores de Workspace.
- Google podría teóricamente bloquear nuevas cuentas personales en dominios ya reclamados por clientes de Workspace o proporcionar controles más sólidos.
Núcleo técnico del problema
- Google trata
user+suffix@domain(y las variantes con puntos) como el mismo buzón queuser@domain, pero permite crear cuentas Google separadas con esas direcciones. - Un empleado puede registrar previamente una cuenta Google no organizacional usando un alias así y luego usar “Iniciar sesión con Google” para acceder a SaaS corporativo incluso después de que su cuenta oficial haya sido desprovisionada.
- El impacto depende de que el SaaS se base únicamente en el reclamo de correo para la autorización; algunos comentaristas subrayan que esto está explícitamente desaconsejado en la documentación de OIDC.
Mitigaciones y buenas prácticas
- Patrones recomendados comentados:
- Usar
iss+subcomo clave de identidad estable, no el correo. - Nunca conceder privilegios únicamente basándose en el dominio del correo.
- Exigir aprovisionamiento explícito o listas de अनुमति para cuentas de SaaS corporativo.
- Enviar verificación de correo independiente o usar “magic link” + 2FA; los críticos señalan inconvenientes de UX y riesgo de phishing.
- Preferir SAML/SCIM o IdPs empresariales dedicados para el control B2B.
- Usar
Debates más amplios sobre OAuth/OIDC e identidad
- Varios participantes describen la autenticación delegada y OIDC como excesivamente complejos, mal comunicados y propensos a errores de configuración.
- Hay desacuerdo sobre si el correo debe tratarse como una identidad principal:
- A favor: comprensible globalmente, ampliamente usado.
- En contra: inestable, reasignable, compartido y no único entre IdPs.
- Algunos ven este incidente como emblemático de un ecosistema de autenticación web desordenado más que como un único momento de “Google OAuth está roto”.