Proteger una API con Azure Active Directory requiere un proceso de registro y configuración de permisos que, aunque puede parecer extenso, sigue una lógica clara: registrar dos aplicaciones, una que representa la API y otra que representa al cliente que la consumirá. A continuación se explica paso a paso cómo realizar esta configuración directamente en el portal de Azure.
¿Por qué se necesitan dos registros de aplicación en Azure AD?
Cuando una API está protegida por Azure Active Directory, no basta con autenticarse; es necesario que la aplicación que consume la API tenga permisos explícitos otorgados en el directorio. Por eso se registran dos aplicaciones [0:25]:
- La primera aplicación representa la API que se va a exponer (en el ejemplo, llamada demo api uno).
- La segunda aplicación representa la app web que obtendrá permisos para interactuar con la API (llamada demo web app uno).
Este modelo de dos registros permite controlar de forma granular quién puede leer, escribir o realizar otras operaciones sobre los recursos expuestos.
¿Cómo registrar y configurar la API en app registrations?
Desde el portal de Azure, se accede a Active Directory y luego a app registrations [1:25]. Al crear el registro para la API:
- Se asigna un nombre identificable, como demo api uno.
- Se selecciona que cualquier cuenta pueda autenticarse.
- En la URI de respuesta se coloca el puerto donde la API estará escuchando, lo que valida que al ejecutar la aplicación el puerto coincida [1:50].
Una vez registrada, se obtiene el Application ID, un identificador clave que se configurará más adelante en Visual Studio [2:15].
El paso siguiente es exponer la API creando alcances (scopes). Los alcances definen qué operaciones puede realizar un cliente autorizado [2:30]:
- Un alcance de lectura (read).
- Un alcance de escritura (write).
Estos alcances funcionan como permisos delegados que la aplicación cliente solicitará al momento de autenticarse.
¿Cómo registrar la aplicación web y otorgarle permisos?
Se regresa a app registrations para crear un segundo registro con el nombre demo web app uno [3:15]. La URI de respuesta apunta al puerto de la aplicación web. Es fundamental que ambas aplicaciones estén corriendo simultáneamente durante el desarrollo, ya que la app web enviará peticiones a la API y esta debe estar lista para validar el token de autorización [3:35].
En la sección de autenticación de la app web, se habilitan dos opciones críticas [4:05]:
- Emitir tokens de acceso (access tokens).
- Emitir ID tokens.
Sin estas opciones activas, la aplicación podrá autenticarse pero no obtendrá los tokens necesarios para consumir la API protegida.
Después, en API permissions, se busca la API registrada previamente (demo api uno) y se seleccionan los permisos de lectura y escritura [4:30]. Es posible diseñar escenarios más elaborados donde una aplicación solo tenga permiso de lectura y otra solo de escritura, pero en este caso se otorgan ambos. Finalmente, se realiza el grant (consentimiento) para que los permisos queden concedidos a nivel de tenant [5:00].
¿Qué datos se necesitan para la configuración en código?
Durante el proceso de registro se recopilan varios valores que serán indispensables al configurar las aplicaciones en Visual Studio [5:10]:
- Application ID de la API: identifica de forma única el registro de la API.
- Application ID de la web app: identifica la aplicación cliente.
- Tenant ID (Directory ID): identifica el directorio de Azure AD.
- Nombre del tenant: se usa en configuraciones posteriores.
- App secret value: se genera en la sección de certificados y secretos.
¿Cómo manejar los secretos de forma segura?
Al crear un client secret para la aplicación web [5:40], es importante copiar el valor inmediatamente, ya que solo se muestra una vez. Si se copia el ID en lugar del valor, la autenticación fallará. En caso de olvidarlo, se debe generar un nuevo secreto.
Esta mecánica también ofrece una ventaja de seguridad: si las credenciales son comprometidas, basta con eliminar el secreto desde el portal para que ningún token emitido con ese secreto pueda seguir consumiendo la API [6:05].
Con estos registros y permisos configurados, la base en Azure AD queda lista. El siguiente paso es llevar estos valores al código fuente para que las aplicaciones se comuniquen de forma segura.
