CIberseguridad Azure: Oauth y OIDC

Estimados amigos de Inseguros !!!

Hoy vamos a tocar un tema que parece “de libro”, pero que en la práctica explica un montón de problemas (y de ataques) en entornos cloud: la diferencia entre OAuth y OpenID Connect (OIDC), cómo se usan los scopes en Entra ID, y por qué el tema de las claves de firma (JWKS) y los tokens es más serio de lo que parece.

OAuth, estrictamente hablando, no nació para “autenticar”, nació para autorizar: darte permisos para acceder a recursos. Como mucha gente lo usaba igualmente para login, apareció OpenID Connect, que es básicamente OAuth con una pieza extra: el ID Token. Ese ID Token no te da permisos sobre Graph ni sobre Azure… te da “atestación”: soy quien digo que soy. Identidad, no autorización.

En Entra ID esto se ve clarísimo cuando juegas con scopes. Por ejemplo, cuando ves https://graph.microsoft.com/.default, ese .default viene a decir “dame los scopes que esta app tiene permitidos”. Y muchas veces lo verás combinado con pedir un ID token: eso ya es un flujo híbrido (te llevas un token “para permisos” y un token “para identidad”).

OIDC además trae el famoso userinfo endpoint: tú le pasas el token y te devuelve información del usuario. ¿Por qué existe todo esto? Porque no queremos que cada web del mundo guarde emails/usuarios/contraseñas de todo el planeta. Lo normal es: tú delegas la identidad a un proveedor (Entra, Google, GitHub, etc.) y tu aplicación solo necesita que el usuario sea único e identificable para personalizar contenido o controlar sesión.

Ahora viene lo interesante para la parte ofensiva/defensiva en cloud: el modelo de confianza de los tokens. En Entra ID hay endpoints “well-known” (configuración) y dentro aparece algo clave: el JWKS URI, donde están las claves públicas con las que se validan los JWT. Y aquí hay un punto delicado: en ciertos escenarios puedes configurar que una aplicación use sus propias claves para validar tokens (en vez de las por defecto). Esto tiene sentido en integraciones legítimas, pero también abre la puerta a ataques si alguien consigue romper la cadena de confianza (por ejemplo, manipulando credenciales/keys de un service principal).

De hecho, una de las cosas que más “molestan” a Microsoft (y con razón) es lo fácil que puede ser, con permisos adecuados, añadir credenciales a un service principal (por ejemplo, una contraseña). Desde el punto de vista de defensa, eso puede ser bastante “sigiloso” si no lo estás monitorizando. Por eso, desde hace un tiempo, cuando creas una app registration aparece el App Instance Lock activado por defecto: impide cambiar claves, reply URLs y credenciales… salvo que alguien deshabilite el lock. Y aquí, como defensores, tenemos un gancho perfecto: si alguien desactiva el lock, eso debería alertarte.

Y si te mola este enfoque “de verdad” (cómo funcionan los tokens, cómo se rompen las confianzas, cómo se abusa de identidades y service principals, y cómo se detecta y se defiende en Entra/Azure), aquí encaja perfecto el Curso de Hacking Azure. 

Y si quieres seguir aprendiendo con contenido aplicado a empresas (Entra ID, Azure, hardening, detección y seguridad cloud), pásate por www.seguridadsi.com y échale un ojo a los cursos de ciberseguridad online para profesionales.

Gracias por leerme !!!