CAPÍTULO 7 · La identidad sale del equipo
Probar el acceso sin cambiar el acceso de todos
Las pruebas del código nos ayudan a detectar regresiones, pero la identidad también tiene configuración fuera del repositorio. Un callback, un secreto o una asignación de usuarios puede afectar el ingreso al servicio. Si usamos indiscriminadamente la misma integración para experimentar y para atender a las personas, una prueba deja de estar realmente aislada.
Separamos las configuraciones de identidad de desarrollo y producción. Cada una debe tener un propósito reconocible y valores que correspondan a su destino. El archivo development.py y el archivo production.py que creamos al principio encuentran aquí otra aplicación: permiten que el proyecto conserve su lógica mientras cambia la integración concreta con el directorio.
La separación reduce confusiones, pero agrega recursos que debemos administrar. Antes de seguir creando registros y servicios conviene poder reconocerlos por su nombre. De lo contrario, el equipo podría configurar correctamente una opción en el recurso equivocado.
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
Dos entornos, dos juegos de llaves
Cada carril muestra un ámbito distinto. Compara sus responsabilidades antes de unir sus configuraciones.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- DEV. Identidad de laboratorio
- Client ID DEV. Credenciales y callbacks propios
- PROD. Identidad productiva
- Client ID PROD. Permisos y secretos separados
01 / EL PROBLEMA
¿Para qué sirve?
Un secreto de laboratorio comprometido no debería dar acceso a la plataforma productiva. Separar identidades permite cambiar permisos, credenciales y responsables con menor alcance de impacto.
02 / COMPRENDER
El concepto, explicado
App Registration define la aplicación; Enterprise Application representa su service principal en un tenant. No son dos servidores ni un proxy por el que necesariamente viajen las peticiones.
Para SensorHub proponemos registros independientes por entorno. Es una decisión de aislamiento del curso, no una exigencia universal de Microsoft. Tener un Client ID distinto ayuda a separar consentimientos y configuración, pero también debes separar datos, secretos y permisos.
MSAL administra el flujo con el proveedor de identidad. Un ID token describe la autenticación del usuario; un access token autoriza la llamada a una API destinataria. No intercambies sus usos.
Una URI local puede coincidir en registros distintos si cada flujo usa el Client ID correspondiente. En producción registra únicamente callbacks necesarios y controla su propiedad.
Registro de aplicaciones define el cliente, sus redirect URIs y credenciales. Aplicaciones empresariales muestra el service principal en el tenant y permite gestionar asignaciones y acceso. Relaciona ambos por el application/client ID; no confundas application object ID, service principal object ID y tenant ID.
03 / CONSTRUIR
Implementación paso a paso
- Enumera aplicaciones web, APIs y entornos antes de registrar identidades.
- Crea registros DEV y PROD con responsables distintos si corresponde y anota Client ID, tenant ID y object IDs.
- Configura las URI de respuesta propias de cada entorno y permisos mínimos de API.
- Guarda credenciales del servidor en el almacén de secretos y documenta su rotación.
- Prueba que un token destinado a DEV sea rechazado por la API PROD y registra el resultado.
04 / APLICAR
Ejemplo en SensorHub
# Ejemplo de contrato de configuración; no contiene credenciales.
IDENTITY_CONFIG = {
"dev": {"client_id_env": "ENTRA_DEV_CLIENT_ID",
"callback": "http://localhost:8000/aad/callback"},
"prod": {"client_id_env": "ENTRA_PROD_CLIENT_ID",
"callback": "https://sensorhub.example/aad/callback"},
}Cómo leer el ejemplo
- El contrato usa nombres de variables, nunca secretos en el repositorio.
- La ruta es una propuesta para una aplicación con MSAL; esta academia no la implementa.
- Cada API debe validar issuer, audience, firma y vigencia mediante una implementación OIDC/JWT mantenida.
Error habitual
Copiar a DEV las credenciales, permisos amplios o datos reales de PROD elimina el aislamiento buscado.
05 / PRACTICAR
Tu turno
Diseña el inventario para SensorHub y una segunda aplicación de inventarios en DEV y PROD.
Ver solución orientativa
Define cuatro registros y sus service principals donde corresponda. Añade propietario, tenant, audiencia, callbacks y almacén de secretos; verifica también la separación de bases de datos.
06 / VERIFICAR
Cómo sabes que funciona
- Los Client ID del proyecto y del entorno se distinguen.
- Rotar DEV no requiere editar PROD.
- Una audiencia incorrecta se rechaza antes del caso de uso.
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:
Convenciones de nombres y ciclo de vida →Continuar en modo relato