CAPÍTULO 7 · La identidad sale del equipo
Cuando la plataforma conduce el ingreso, la configuración cambia
Supongamos que otro proyecto decide utilizar Easy Auth. En ese caso no basta con conservar el código de MSAL y cambiar una variable interna. La autenticación ocurre antes de la aplicación y necesita un proveedor, un registro y URLs de retorno coherentes con ese mecanismo. El portal pasa a formar parte del recorrido efectivo del usuario.
Revisamos cómo se relacionan esas piezas y qué debe pasar con una solicitud no autenticada. También comprobamos qué señales puede aceptar el backend y bajo qué condiciones de confianza. La lección permite reconocer el flujo completo de esta alternativa, mientras SensorHub conserva como referencia principal el login gestionado en Django.
Elegir una de las rutas resuelve quién procesa la autenticación, pero no quién administra a las personas que usarán el servicio. Cuando la plataforma debe colaborar con usuarios externos, aparece una necesidad organizativa: delegar tareas de acceso sin repartir control sobre todo el directorio.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Conectar proveedor y destino correcto
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- App Service. Selecciona recurso y entorno
- Registro. Configura tenant y Client ID
- Callback. Coincide con URI registrada
- Pruebas. Acceso válido y denegaciones
01 / EL PROBLEMA
¿Para qué sirve?
Un proveedor configurado en el recurso equivocado o con una URI de respuesta incorrecta puede bloquear a todos los usuarios después de publicar.
02 / COMPRENDER
El concepto, explicado
Este tema es el recorrido alternativo Easy Auth. Solo configures el proveedor Microsoft en App Service Authentication cuando elijas que la plataforma autentique. Si sigues MSAL propio, mantén Authentication desactivado y continúa con el callback de Django.
La configuración pertenece a un App Service concreto y debe revisarse también en sus slots. DEV y PROD necesitan su configuración, credenciales y URI de respuesta correspondientes.
El callback habitual del proveedor Entra es /.auth/login/aad/callback bajo el dominio que atiende el flujo. No lo confundas con la ruta elegida por una aplicación que implementa MSAL.
Tenant, emisores permitidos y audiencias determinan qué identidad y token se aceptan. Autenticarse en algún tenant no implica estar autorizado en el tenant esperado.
La configuración del portal puede evolucionar; confirma los nombres de opciones en la referencia enlazada y conserva evidencia de la configuración efectiva.
03 / CONSTRUIR
Implementación paso a paso
- En un entorno de laboratorio abre App Services y selecciona el recurso por su ID.
- En Authentication agrega el proveedor Microsoft con el registro del entorno.
- Revisa tenant, Client ID, credencial y callback exacto en el registro.
- Para una web privada exige autenticación y configura redirección; para una API acuerda 401.
- Si se requiere asignación configúrala en la Enterprise Application y prueba permisos internos.
- Verifica login, logout, usuario no asignado y tenant incorrecto antes de habilitarlo en producción.
04 / APLICAR
Ejemplo en SensorHub
# Lista de comprobación para el laboratorio; no crea recursos.
easy_auth_contract = {
"environment": "dev",
"provider": "Microsoft Entra ID",
"callback": "https://sensorhub-dev.azurewebsites.net/.auth/login/aad/callback",
"anonymous_web": "redirect",
"anonymous_api": "401",
"tenant": "<TENANT_ID_DEV>",
"client_id": "<CLIENT_ID_DEV>",
}Cómo leer el ejemplo
- Los marcadores se sustituyen por IDs del laboratorio.
- Web y API pueden requerir recursos o reglas separadas para sus respuestas anónimas.
- La comprobación se realiza en otro proyecto: la academia mantiene acceso público.
Error habitual
Copiar un callback de PROD a DEV o suponer que activar el proveedor exige asignación automáticamente.
05 / PRACTICAR
Tu turno
El navegador informa redirect_uri_mismatch. Describe el diagnóstico sin cambiar permisos de negocio.
Ver solución orientativa
Compara protocolo, dominio y ruta de la URI enviada con las registradas; confirma Client ID y entorno. Si hay proxy o dominio personalizado revisa el host efectivo y el flujo externo.
06 / VERIFICAR
Cómo sabes que funciona
- Callback coincide exactamente con el registro.
- El recurso y el registro pertenecen al entorno esperado.
- Un usuario sin autorización no ejecuta acciones internas.
Para profundizar
Documentación oficial para comprobar configuración, permisos y condiciones vigentes. Revisión del tema: 2026-10-11.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Delegación de invitados y acceso a una aplicación →Continuar en modo relato