¿Por qué necesito el registro de aplicaciones en Azure y cómo se relacionan con mi servicio de aplicaciones?
He leído algo sobre Azure AD, pero aún no logro entenderlo. La confusión podría estar ahí también debido a cómo mi empresa intenta estandarizar cómo debería verse un proyecto de Azure.
Imagina que tengo dos cosas: una aplicación SPA (servida por App Service) y una API (en este App Service, ASP.NET). El enfoque que la empresa sugiere es que ambas deben tener sus registros de aplicación.
Ahora, me gustaría que la API tuviera acceso a Microsoft Graph. Para hacer esto, al ver otros proyectos, actualicé mi registro de aplicación para solicitar roles de Microsoft Graph, el administrador otorgó su consentimiento y en la API utilicé ConfidentialClient para reutilizar mi Id. de cliente/secreto para obtener un token y luego acceder a Microsoft Graph.
¿Por qué tanto esfuerzo? ¿Por qué no usar simplemente la Identidad Administrada de mi API y otorgar los permisos necesarios utilizando New-AzureAdServiceAppRoleAssignment?
¿Por qué necesito un registro de aplicación aquí? ¿Los necesito a ambos? ¿Debo acceder a Microsoft Graph usando mi registro de aplicación y cliente confidencial en mi API? ¿Cómo se relaciona mi App Service con mi registro de aplicación en el código?
davy.ai
Azure Active Directory (AAD) es el servicio de gestión de identidad y acceso basado en la nube de Microsoft que ayuda a gestionar usuarios y aplicaciones. Las aplicaciones y servicios que utilizan AAD pueden autenticar a los usuarios con sus cuentas organizativas o de Microsoft, y gestionar permisos para proteger los recursos.
En el escenario que mencionaste, tanto la aplicación SPA como la API necesitan autenticarse y autorizarse con AAD. El registro de aplicaciones es el proceso de registrar su aplicación con AAD. Crea una identidad para su aplicación en AAD, lo que le permite a AAD autenticar su aplicación y autorizar el acceso a las APIs, como Microsoft Graph.
Si bien la empresa sugiere tener registros de aplicaciones separados para cada aplicación (SPA y API), no es obligatorio. Podría utilizar un único registro de aplicación para tanto la aplicación SPA como la API si forman parte de la misma aplicación lógica.
Si desea acceder a Microsoft Graph desde la API, tiene varias opciones. Podría utilizar un cliente confidencial, como mencionó, para obtener un token y acceder a la API de Graph. Esto requiere un ID de cliente y una clave secreta, que se almacenan de forma segura en la configuración de su aplicación.
Alternativamente, podría utilizar la identidad administrada, que es una función que proporciona una identidad administrada automáticamente en Azure. Cuando una aplicación o servicio está configurado con la identidad administrada, obtiene una identidad generada automáticamente que puede utilizar para autenticarse con otros servicios de Azure, incluido AAD.
En el caso de acceder a Microsoft Graph, podría utilizar New-AzureAdServiceAppRoleAssignment para otorgar los permisos necesarios a la identidad administrada de la API. Esto elimina la necesidad de un ID de cliente y una clave secreta, ya que la identidad es administrada por Azure.
En conclusión, el registro de aplicaciones es necesario para la autenticación y autorización de aplicaciones con AAD, pero depende del desarrollador determinar el número de registros requeridos. Tanto los clientes confidenciales como la identidad administrada tienen sus casos de uso y pueden aprovecharse dependiendo del escenario. Su servicio de aplicación se relaciona con su registro de aplicación a través de la configuración, como el ID de cliente, la clave secreta y el ID de inquilino.