Protocolos de Autenticación en Azure Active Directory
Contenido del curso
Eduardo Alan Gonzalez Garduño
Protocolos y tipos de aplicaciones
La plataforma de identidad de Microsoft admite la autenticación de diversas arquitecturas de aplicaciones modernas, las cuales están basadas en protocolos estándar del sector OAuth 2.0 u OpenID Connect.
Debes registrar cada aplicación que utiliza la plataforma de identidad de Microsoft utilizando el “registro de aplicaciones” dentro del portal de Azure
Azure de esta manera recopila y asigna los siguientes valores:
• Identificador de la aplicación (Cliente) • URL de redirección (Para dirigir las respuestas de nuevo a la aplicación) • Tipos de cuentas compatibles.
Fernando Sánchez Mejía
Gracias por el resumen.
Julian Torres
Notas.
Fernando Sánchez Mejía
Gracias por el aporte.
Fernando Sánchez Mejía
AD ocupa ptotocolos de OpenID para autenticarnos y Outh 2.0 para llevar a cabo la autorización.
Fernando Sánchez Mejía
Cuando aplicamos un flujo debe esta relacionado a una aplicación (movil/web) que esta registrado en AD.
Fernando Sánchez Mejía
Al registrar una aplicación se obtiene el identificador de la aplicación, la Uri de redirección para dirigir las respuestas y el tipo de cuentas compatibles.
Andrés Marín Sánchez
En este punto del Curso, tengo varias dudas:
Ya que estoy tomando este curso con la idea de poder integrar Azure Active Directory con el Directorio Activo de Windows, entonces estoy un poco perdido... Estoy muy mal o se deberia hacer una diferenciación para que sirve cada "Active Directory" o una definición inicial ya que aún no lo tengo tan claro.
Muchas gracias!
Daniel Guerrero
Es una buena clase en estructura y ambición, pero desde un punto de vista técnico, pedagógico y de alineación con Microsoft Entra ID, necesita ajustes finos para que sea 100% correcta, consistente y “a prueba” de malentendidos (especialmente para alumnos AZ-900 / AZ-204 / arquitectura).
Voy a darte una evaluación honesta en 4 capas:
🟢 1️⃣ Lo que está bien (y está bien hecho)
✔️ Enfoque general
👉 Esto demuestra buen entendimiento conceptual.
✔️ Secuencia didáctica
La progresión es lógica:
👉 Muy buena narrativa para una clase.
🟡 2️⃣ Imprecisiones técnicas (importantes de corregir)
Aquí es donde hay que ser cuidadoso.
⚠️ A) “OAuth 2.0 para tareas de autorización”
Correcto pero incompleto.
✔️ OAuth 2.0 autoriza ⚠️ Pero en Azure casi siempre va acompañado de OpenID Connect
📌 Riesgo pedagógico: El alumno puede pensar que OAuth “autentica”.
✅ Ajuste recomendado:
OpenID Connect se utiliza para autenticación y OAuth 2.0 para autorización y acceso a recursos.
⚠️ B) “Authorization Code Flow” en SPA (sin aclaración)
Hoy esto solo es correcto si se menciona PKCE.
❌ Authorization Code Flow “clásico” en SPA ya no es seguro.
✅ Forma correcta:
Authorization Code Flow con PKCE
📌 Microsoft lo exige en:
⚠️ C) Flujo de aplicaciones web (detalle clave)
Dices:
“devuelve un ID token al navegador”
Esto es parcial.
✔️ Se devuelve un ID token ✔️ Pero normalmente también se obtiene un access token (directo o vía backend)
📌 Para APIs:
⚠️ D) Server-to-server: falta nombrar el flujo
El escenario está bien descrito, pero no se nombra el flujo correcto.
Debe decir explícitamente:
📌 En formación, nombrar el flujo es clave.
⚠️ E) Refresh token (matiz importante)
Dices:
“la aplicación debe utilizar el refresh token”
Esto es correcto pero no universal.
📌 Aclaración necesaria:
🔵 3️⃣ Versión corregida (sin reescribir toda la clase)
Te dejo una versión ajustada conceptual, manteniendo tu estructura:
Clase 9 – Protocolos de Autenticación en Microsoft Entra ID
Microsoft Entra ID (antes Azure Active Directory) proporciona protocolos estándar para la gestión segura de identidad y acceso. OpenID Connect se utiliza para la autenticación de usuarios, mientras que OAuth 2.0 permite la autorización y el acceso controlado a recursos mediante tokens.
Integración con aplicaciones
Al registrar una aplicación en Entra ID se crea una identidad para dicha aplicación, incluyendo un identificador único y URIs de redirección previamente autorizadas. Estas URIs determinan a dónde se devuelve el usuario tras completar el proceso de autenticación, junto con los tokens emitidos. Además, se define el tipo de cuentas admitidas (single-tenant, multi-tenant o cuentas Microsoft).
Aplicaciones de una sola página (SPA)
Las SPA utilizan Authorization Code Flow con PKCE, donde:
Aplicaciones web
En aplicaciones web tradicionales:
Aplicaciones móviles
Las apps móviles emplean Authorization Code Flow con PKCE, usando el navegador del sistema. Cuando el access token expira, puede renovarse usando un refresh token, si el flujo lo permite.
Comunicación server-to-server
En escenarios sin interacción humana se utiliza el Client Credentials Flow:
Gestión de tokens
La validación, expiración y renovación de tokens debe gestionarse cuidadosamente. Las URIs de redirección deben estar registradas explícitamente para evitar ataques de redirección y garantizar la seguridad del flujo.
🧠 4️⃣ Veredicto final
⭐ Evaluación general: 8.5 / 10
✔️ Excelente estructura ✔️ Casos bien cubiertos ✔️ Lenguaje claro ⚠️ Algunos matices técnicos críticos ⚠️ Faltaban nombres formales de flujos y PKCE
Con los ajustes: ➡️ Clase sólida, profesional y alineada con Microsoft Learn / AZ-900 / AZ-204
🎯 Frase de cierre ideal para la clase
Entender los flujos de autenticación en Entra ID no es memorizar pasos, sino comprender qué entidad confía en quién y por qué.
Francisco Marín
Identidad: Se refiere a un usuario. Pero las aplicaciones también tienen identidad.
Fernando Sánchez Mejía
Si la Uri de respuesta no esta registrada en AD, por seguridad nos indica que no la conoce. Que se debe tener acceso a la aplicación en AD para agregarla y poder utilizarla.
