Una nueva investigación sugiere que más de 10.000 aplicaciones SaaS podrían seguir siendo vulnerables a una variante de nOAuth a pesar de que el problema básico se reveló en junio de 2023.

Una nueva investigación sugiere que más de 10.000 aplicaciones SaaS podrían seguir siendo vulnerables a una variante de nOAuth a pesar de que el problema básico se reveló en junio de 2023.

nOAuth se describe mejor como una metodología de abuso utilizada para abordar una configuración incorrecta o una práctica de desarrollo deficiente en la interfaz entre las aplicaciones SaaS y Entra ID. El usuario de SaaS es la víctima. 

Es prácticamente imposible para un usuario de SaaS saber si es víctima de nOAuth, y no existen opciones de mitigación. La víctima puede tener sus propios controles de seguridad exhaustivos, pero nOAuth se produce entre SaaS y Entra, fuera del alcance de cualquier sistema de seguridad local. 

Hacia finales de 2024, los investigadores de Semperis comenzaron a analizar las aplicaciones SaaS incluidas en la Galería Microsoft Entra. El objetivo no era repetir la investigación de Descope , sino comprobar si la metodología nOAuth podía implementarse mediante un enfoque multiusuario en lugar del escenario de múltiples proveedores de identidad de Descope.

Los investigadores seleccionaron 104 aplicaciones SaaS de la Galería Microsoft Entra. “En esencia, el cliente objetivo (víctima) es un cliente de Microsoft con un inquilino de Entra ID, y el atacante utiliza un inquilino de Entra ID diferente para cometer el abuso”, explican . Funciona. La aplicación SaaS solo necesita ser compatible con Entra ID para que la autenticación sea susceptible a nOAuth. Si bien muchas aplicaciones pueden haber seguido el consejo de cerrar la puerta detectado por Descope (que involucra a múltiples proveedores de identidad), relativamente pocas son conscientes de que solo se necesita el Entra ID para invocar nOAuth. 

El estudio de Descope se centró en los flujos de fusión de cuentas; por ejemplo, si la aplicación SaaS era compatible con Google y Microsoft (Entra ID). En nuestro estudio, descubrimos que el mismo tipo de abuso puede existir incluso si la aplicación solo usa Entra ID y solo consulta la solicitud de correo electrónico, explica Eric Woodruff, arquitecto jefe de identidad de Semperis. 

Continuó: «Muchos desarrolladores podrían haber leído la investigación de Descope y pensar: ‘Esto no nos afecta’. También hubo algunos informes inexactos en aquel momento, que decían que nOAuth estaba ‘solucionado’. Los titulares harían creer que Microsoft hizo algo para resolverlo de forma generalizada».

No se solucionó. Microsoft proporcionó consejos sobre cómo configurar correctamente Entra ID. nOAuth se puede prevenir, pero no se puede solucionar.

De las 104 aplicaciones investigadas, Semperis descubrió que nueve eran vulnerables a nOAuth (aproximadamente el 9%). Es difícil saber cómo se podrían aplicar estos resultados a todo el ecosistema SaaS, pero Woodruff comenta: «Si hay, por ejemplo, 44 000 empresas SaaS, y varias de ellas tienen múltiples productos, no sería descabellado pensar que podría haber 150 000 aplicaciones SaaS en circulación».

De las aplicaciones analizadas, el 9 % resultó vulnerable. “Por lo tanto, si extrapolamos esta cifra a 150 000 aplicaciones, serían 13 500 las que podrían ser vulnerables”. Entre las aplicaciones SaaS vulnerables que Semperis encontró se encontraban una plataforma de gestión de recursos humanos (probablemente llena de información de identificación personal) y otras aplicaciones que se integraban con Microsoft 365. En este último caso, un abuso exitoso de nOAuth permitiría al atacante acceder a los datos SaaS y, potencialmente, acceder a los recursos de Microsoft 365.

Semperis informó a Microsoft sobre su investigación. Abrió un caso ante MSRC en diciembre de 2024, pero recibió poca respuesta de MSRC, que lo cerró sin proporcionar detalles en abril de 2025. SecurityWeek ha invitado a Microsoft a comentar sobre la investigación de Semperis, pero no ha recibido respuesta al momento de escribir este artículo (si recibimos una respuesta, la incluiremos como apéndice a este artículo).

Pero este no es un problema que Microsoft pueda solucionar; se trata fundamentalmente de un problema de arquitectura que afecta al punto final de autenticación/autorización para todos los inquilinos de Entra y a la necesidad legítima de que las cuentas de invitado tengan una dirección de correo electrónico, incluidas las direcciones no verificadas. Microsoft ha creado una plataforma que, si se configura e implementa correctamente, no será vulnerable a nOAuth. 

Este es el problema. Los desarrolladores siempre están bajo presión para entregar con rapidez y pueden malinterpretar fácilmente las instrucciones detalladas y hacer suposiciones erróneas sobre lo que se requiere. Los detalles de la investigación de Semperis sugieren que esto es generalizado.

En definitiva, nOAuth no es una vulnerabilidad solucionable, sino una configuración incorrecta que puede explotarse. Microsoft puede ofrecer consejos e instrucciones sobre cómo hacerlo correctamente, pero no puede obligar a los desarrolladores a seguir las reglas.

El resultado final es que nOAuth continúa, las víctimas no saben que son víctimas, Microsoft no puede solucionar el problema y los desarrolladores, que son los únicos que pueden evitar nOAuth, hasta ahora no han podido hacerlo.