Cómo el consentimiento de OAuth evita MFA

En febrero de 2026, una plataforma de phishing como servicio (PhaaS) llamada tokens malvados salió en vivo. En cinco semanas, había comprometido a más de 340 organizaciones de Microsoft 365 en cinco países.

Los objetivos de la plataforma recibieron un mensaje pidiéndoles que ingresaran un código corto en microsoft.com/devicelogin y completaran su desafío MFA normal, luego se marcharon creyendo que habían verificado un inicio de sesión de rutina. De hecho, le habían entregado al operador un token de actualización válido destinado a su buzón, unidad, calendario y contactos, con la vida útil de una política de inquilino en lugar de una sesión.

El operador nunca necesitó una contraseña, nunca activó un mensaje de MFA y nunca produjo un evento de inicio de sesión que pareciera una intrusión. El ataque tuvo éxito porque la pantalla de consentimiento de OAuth se convirtió en un clic instintivo y los controles creados para detener el phishing de credenciales no miran la capa de consentimiento.

Los investigadores de seguridad llaman a la condición resultante phishing de consentimiento o abuso de concesión de OAuth. El clic de phishing que importó la última década entregó una contraseña. El clic de phishing que importa ahora entrega un token de actualización y se ubica estructuralmente debajo de los controles de identidad que la mayoría de las organizaciones todavía consideran como perímetro.

Por qué MFA no puede ver una concesión de OAuth

Un phishing de credenciales entrega un nombre de usuario y una contraseña que deben reproducirse en algún lugar, y la mayoría de las pilas de identidades ahora exigen un segundo factor en la repetición. Incluso los kits de adversario en el medio (AiTM) producen una cookie de sesión vinculada a un evento de inicio de sesión que el SIEM correlaciona con la geografía, el dispositivo y los patrones de viaje.

Figura 1: El phishing de credenciales deja un rastro de inicio de sesión que SIEM puede correlacionar.

Una concesión de OAuth no produce credenciales repetidas. El usuario se autentica en el proveedor de identidad legítimo, finaliza la verificación de MFA en el dominio legítimo y hace clic en Aceptar. La señal que se lleva el atacante es que el sistema funciona según lo diseñado. Está firmado por el proveedor de identidad, tiene como alcance lo que el usuario acordó y es actualizable. MFA no puede bloquearlo porque MFA ya ocurrió.

Figura 2: Una concesión de OAuth no deja repetición, solo un token actualizable.

El otro problema es que los tokens de actualización amplían la ventana. Los tokens emitidos por EvilTokens sobrevivieron a los restablecimientos de contraseñas y permanecieron válidos durante semanas o meses, según la configuración del inquilino. Rotar la contraseña no invalidó la concesión. Sólo la revocación explícita, o una política de acceso condicional que exigía un nuevo consentimiento, lo cerró.

Cómo se normalizó el consentimiento

Este vector de ataque existe desde que OAuth se convirtió en estándar. Lo que cambió es el entorno en el que opera. Los usuarios han sido capacitados para hacer clic en las pantallas de consentimiento al mismo ritmo que una vez hicieron clic en los carteles de cookies. Cada agente de IA instala Surface One. Cada integración de productividad genera una. Cada extensión del navegador que toca una cuenta SaaS muestra una. El volumen de consentimiento legítimo que ve un trabajador del conocimiento en un mes excede todo lo que existía cuando se escribieron los modelos de amenazas originales de OAuth.

Los propios alcances utilizan un lenguaje que no se relaciona claramente con el riesgo. Un alcance llamado «Leer su correo» parece limitado, pero en la práctica cubre todos los mensajes, archivos adjuntos e hilos compartidos al que puede acceder el usuario. Un alcance llamado «Acceder a archivos cuando no esté presente» significa un token de larga duración emitido sin que el usuario esté frente a una pantalla para revocarlo. La brecha entre el lenguaje de consentimiento y el alcance operativo es exactamente donde operan los atacantes.

Formulario de combinaciones tóxicas debajo del propietario de la aplicación

Un consentimiento único de OAuth le da al atacante un punto de apoyo dentro de una aplicación. El riesgo más profundo se forma cuando esos puntos de apoyo se unen.

Un usuario de finanzas otorga a un resumidor de reuniones de IA acceso a su calendario y buzón de correo. Posteriormente, el mismo usuario otorga acceso a un asistente de productividad al disco compartido de la empresa. Una tercera subvención conecta una herramienta de enriquecimiento de CRM con la base de datos de clientes. Cada uno fue aprobado uno a la vez. Ningún propietario de la aplicación aprobó la combinación. La superficie de riesgo ahora son tres ámbitos que se cruzan a través de una identidad humana, donde el compromiso del resumidor de la reunión puede llegar a borradores de contratos y registros de clientes a través de la misma persona.

Esto se llama un combinación tóxica. Consiste en un desglose de permisos entre aplicaciones, unido por una concesión de OAuth, una integración o un agente de IA, que ningún propietario de la aplicación jamás autorizó como su propia superficie de riesgo. No puede ser visto por el registro de auditoría de ninguna aplicación porque el puente existe fuera de todas ellas.

Figura 3: Una combinación tóxica entre dos aplicaciones SaaS que ningún propietario aprobó juntas.

La instalación de MCP, el clic de consentimiento de OAuth y la concesión de extensión del navegador: cada uno es un puente emitido a la velocidad de un solo clic. Los servidores Model Context Protocol (MCP) están surgiendo como la próxima superficie de ataque estilo OAuth, permitiendo a los agentes adquirir alcance a través del mismo mecanismo de confianza que ya utilizan las pantallas de consentimiento.

El Salesloft-Drift 2025 incidente mostró cómo se ve esto a escala. Un conector descendente comprometido se extendió entre más de 700 inquilinos de Salesforce a través de tokens OAuth que los clientes habían aprobado legítimamente. Cada cliente autorizó la integración. Ninguno autorizó la cascada.

Qué comprobar

Para cerrar esta brecha es necesario tratar el consentimiento de OAuth de la misma manera que el programa de seguridad ya trata la autenticación. Un pequeño conjunto de preguntas expone dónde reside la verdadera brecha.

La disciplina procesal sólo escala hasta ahora. Los puentes viven en un gráfico que ninguna aplicación individual posee y se crean a la velocidad de una instalación de MCP o un clic de consentimiento de OAuth. Ver ese gráfico continuamente requiere una plataforma construida para observar la capa de tiempo de ejecución donde realmente se forman los puentes.

Dónde encajan las plataformas de seguridad de IA

Una nueva clase de plataformas maneja mucho de esto automáticamente. Mapean cada concesión de OAuth, agente de IA e integración de terceros en el gráfico de identidad en el momento en que se emite, en lugar de esperar a la siguiente auditoría, y luego muestran los puentes, los tokens no utilizados y las desviaciones de políticas como una cola operativa continua.

Un ejemplo destacado es Reco. Reúne la seguridad de los agentes de IA, el control de identidades y la detección de amenazas en un solo plano de control. Su Identity Knowledge Graph conecta identidades humanas y no humanas con las aplicaciones, subvenciones de OAuth e integraciones a las que pueden acceder en todo el patrimonio SaaS.

Figura 4: Vista de Reco de las concesiones OAuth y las cuentas conectadas de un agente de IA.

La plataforma descubre continuamente agentes de IA y concesiones de OAuth a medida que aparecen, asigna cada alcance a la identidad que lo aprobó, monitorea el comportamiento para detectar desviaciones de políticas y revoca el acceso a nivel de token en lugar de a la cuenta de usuario. Esto brinda a los equipos de seguridad visibilidad de la capa de tiempo de ejecución donde realmente se forman estas relaciones de confianza.

El phishing de consentimiento probablemente no permanecerá al margen por mucho más tiempo. La autenticación resistente al phishing ha recibido años de inversión y escrutinio, mientras que la capa de consentimiento todavía funciona en gran medida basándose en la confianza. Cerrar esa brecha significa tratar las concesiones de OAuth y las conexiones de agentes de IA con la misma disciplina de visibilidad, monitoreo y revocación que ya se aplica a la autenticación misma.

Obtenga más información sobre la plataforma de seguridad de IA de Reco.