En febrero de 2026, la plataforma **EvilTokens** salió al público, demostrando rápidamente los peligros del consentimiento OAuth sin control. Los objetivos fueron engañados para ingresar un código en `microsoft.com/devicelogin` y completar un desafío de MFA, otorgando sin saberlo a los atacantes un token de actualización con amplios permisos, incluido el acceso a buzones, unidades, calendarios y contactos. Este token persistió según la política del tenant, superando con creces la vida útil de una sesión típica. Este ataque elude las medidas de seguridad tradicionales, ya que no implica contraseñas robadas ni eventos de inicio de sesión sospechosos. En cambio, explota la normalización de las pantallas de consentimiento OAuth, donde los usuarios a menudo hacen clic instintivamente en 'Aceptar' sin comprender completamente los permisos otorgados. ## Por qué MFA Falla Contra el Abuso de Concesión OAuth El phishing de credenciales tradicional se basa en la reproducción de nombres de usuario y contraseñas robados, lo que activa las indicaciones de MFA y deja un rastro para que los sistemas de gestión de eventos e información de seguridad (SIEM) los detecten. Sin embargo, el abuso de concesión OAuth no produce tal reproducción. El usuario se autentica en el proveedor de identidad legítimo, completa la MFA y otorga el consentimiento. El token resultante es válido, firmado por el proveedor de identidad y actualizable, lo que hace que la MFA sea ineficaz para bloquear el ataque. <table><tbody><tr><td></td></tr><tr><td>Figura 1: El phishing de credenciales deja un rastro de inicio de sesión que el SIEM puede correlacionar.</td></tr></tbody></table> <table><tbody><tr><td></td></tr><tr><td>Figura 2: Una concesión OAuth no deja reproducción, solo un token actualizable.</td></tr></tbody></table> Además, los tokens de actualización emitidos por **EvilTokens** permanecieron válidos incluso después de restablecer contraseñas, persistiendo durante semanas o meses según la configuración del tenant. Solo la revocación explícita o las políticas de acceso condicional que requieren un nuevo consentimiento podrían terminar la concesión. ## La Normalización del Consentimiento El vector de ataque de consentimiento OAuth no es nuevo, pero su efectividad ha aumentado debido a la desensibilización del usuario. Los usuarios son bombardeados con pantallas de consentimiento de agentes de IA, integraciones de productividad y extensiones de navegador, lo que lleva a una mentalidad de "clic y continuar" similar a los banners de cookies. El lenguaje utilizado en los alcances de consentimiento a menudo oculta el alcance real de los permisos otorgados. Por ejemplo, "Leer tu correo" puede abarcar cada mensaje, archivo adjunto y hilo compartido. Esta discrepancia entre el lenguaje de consentimiento y el alcance operativo es explotada por los atacantes. ## Combinaciones Tóxicas: Riesgo Inter-Aplicaciones El verdadero peligro radica en la combinación de múltiples consentimientos OAuth en diferentes aplicaciones, creando lo que los investigadores llaman "combinaciones tóxicas". Por ejemplo, un usuario de finanzas que otorga acceso a su calendario y buzón a un resumidor de reuniones de IA, y luego otorga acceso a la unidad compartida de la empresa a un asistente de productividad, crea una superficie de riesgo donde un compromiso en una aplicación puede extenderse a otras. <table><tbody><tr><td></td></tr><tr><td>Figura 3: Una combinación tóxica entre dos aplicaciones SaaS que ningún propietario sancionó conjuntamente.</td></tr></tbody></table> El incidente de **Salesloft**-**Drift** en 2025 destacó este riesgo a escala. Un conector descendente comprometido se propagó a través de más de 700 tenants de **Salesforce** mediante tokens OAuth legítimos, demostrando el efecto cascada de las integraciones comprometidas. ## Medidas Proactivas para Mitigar Riesgos de OAuth Las organizaciones deben tratar el consentimiento OAuth con el mismo rigor que la autenticación. Las áreas clave a revisar incluyen: * **Inventario de Aplicaciones OAuth:** Monitorear continuamente todas las aplicaciones de terceros que poseen tokens de actualización. * **Antigüedad de la Concesión y Nuevo Consentimiento:** Marcar tokens emitidos hace mucho tiempo sin un nuevo consentimiento. * **Identidades Inter-Aplicaciones:** Identificar identidades que poseen concesiones en múltiples aplicaciones SaaS. * **Puentes de Agentes e Integraciones:** Detectar agentes de IA e integraciones que conectan sistemas sin autorización explícita. * **Acceso Condicional en el Consentimiento:** Implementar políticas activadas por eventos de consentimiento, no solo por eventos de inicio de sesión. * **Revocación a Nivel de Token:** Establecer playbooks para revocar tokens OAuth individuales. Estas medidas requieren una plataforma capaz de monitorear continuamente la capa de tiempo de ejecución donde se forman estos puentes, ya que la disciplina procesal por sí sola no puede escalar para abordar la velocidad a la que surgen estos riesgos. ## Plataformas de Seguridad de IA Está surgiendo una nueva clase de plataformas para automatizar gran parte de este proceso, mapeando concesiones OAuth, agentes de IA e integraciones de terceros para proporcionar visibilidad y control integrales sobre el panorama de OAuth.