Descripción del acceso de solo aplicación
Cuando una aplicación accede directamente a un recurso, como Microsoft Graph, su acceso no se limita a los archivos u operaciones disponibles para cualquier usuario único. La aplicación llama a las API directamente mediante su propia identidad y un usuario o aplicación con derechos de administrador debe autorizarla para acceder a los recursos. Este escenario se conoce como acceso de solo aplicación.
¿Cuándo debo usar el acceso de solo aplicación?
En la mayoría de los casos, el acceso de solo aplicación es más amplio y eficaz que el acceso delegado, por lo que solo debe usar el acceso de solo aplicación cuando sea necesario. Normalmente es la opción correcta si:
- La aplicación debe ejecutarse de forma automatizada, sin entrada del usuario. Por ejemplo, un script diario que comprueba los correos electrónicos de determinados contactos y envía respuestas automatizadas.
- La aplicación debe tener acceso a los recursos que pertenecen a varios usuarios diferentes. Por ejemplo, una aplicación de prevención de pérdida de datos o de copia de seguridad podría necesitar recuperar mensajes de muchos canales de chat diferentes, cada uno con participantes diferentes.
- Siente la tentación de almacenar las credenciales localmente y permitir que la aplicación inicie sesión "como" usuario o administrador.
Por el contrario, nunca debe usar el acceso de solo aplicación cuando un usuario normalmente iniciaría sesión para administrar sus propios recursos. Estos tipos de escenarios deben usar el acceso delegado para tener privilegios mínimos.
Autorización de una aplicación para realizar llamadas de solo aplicación
Para realizar llamadas de solo aplicación, debe asignar a la aplicación cliente los roles de aplicación adecuados. Los roles de aplicación también se conocen como permisos de solo aplicación. Son roles de aplicación porque conceden acceso solo en el contexto de la aplicación de recursos que define el rol.
Por ejemplo, para leer una lista de todos los equipos creados en una organización, debe asignar a la aplicación el rol de aplicación Team.ReadBasic.All de Microsoft Graph. Este rol de aplicación concede la capacidad de leer estos datos cuando Microsoft Graph es la aplicación de recursos. Esta asignación no asigna la aplicación cliente a un rol de Teams que pueda permitirle ver estos datos a través de otros servicios.
Como desarrollador, debe configurar todos los permisos de solo aplicación necesarios, también denominados roles de aplicación en el registro de aplicaciones. Puede configurar los permisos de solo aplicación solicitados de la aplicación a través de Azure Portal o Microsoft Graph. El acceso de solo aplicación no admite el consentimiento dinámico, por lo que no puede solicitar permisos individuales ni conjuntos de permisos en tiempo de ejecución.
Una vez que haya configurado todos los permisos que necesita la aplicación, debe obtener el consentimiento del administrador para que pueda acceder a los recursos. Por ejemplo, solo los usuarios con al menos el rol Administrador de roles con privilegios pueden conceder permisos solo para aplicaciones (roles de aplicaciones) para la API de Microsoft Graph. Los usuarios con otros roles de administrador, como Administrador de aplicaciones y Administrador de aplicaciones en la nube, pueden conceder permisos de solo aplicación para otros recursos.
Los usuarios administradores pueden conceder permisos de solo aplicación mediante Azure Portal o la creación de concesiones mediante programación a través de Microsoft Graph API. También puede solicitar el consentimiento interactivo desde de la aplicación, pero esta opción no es la preferida, ya que el acceso de solo aplicación no requiere un usuario.
Los usuarios consumidores con cuentas de Microsoft, como cuentas de Xbox Live o Outlook.com, nunca pueden autorizar el acceso de solo aplicación.
Siga siempre el principio de privilegios mínimos: nunca debe solicitar roles de aplicación que la aplicación no necesite. Este principio ayuda a limitar el riesgo de seguridad si la aplicación está en peligro y facilita a los administradores conceder acceso a la aplicación. Por ejemplo, si la aplicación solo necesita identificar a los usuarios sin leer la información detallada del perfil, debe solicitar el rol de aplicación User.ReadBasic.All de Microsoft Graph más limitado en lugar de User.Read.All.
Diseño y publicación de roles de aplicación para un servicio de recursos
Si va a crear un servicio en Microsoft Entra ID que expone las API para que otros clientes realicen llamadas, es posible que desee admitir el acceso automatizado con roles de aplicación (permisos de solo aplicación). Puede definir los roles de aplicación para la aplicación en la sección Roles de aplicación del registro de la aplicación en el centro de administración de Microsoft Entra. Para obtener más información sobre cómo crear roles de aplicación, consulte Declaración de roles para una aplicación.
Al exponer roles de aplicación para que otros usuarios los utilicen, proporcione descripciones claras del escenario al administrador que los va a asignar. Por lo general, los roles de aplicación deben ser lo más limitados posible y admitir escenarios funcionales específicos, ya que el acceso de solo aplicación no está restringido por los permisos del usuario. Evite exponer un solo rol que conceda acceso completo de read o de read/write a todas las API y recursos que contiene el servicio.
Nota
Los roles de aplicación (permisos de solo aplicación) también se pueden configurar para admitir la asignación a usuarios y grupos. Asegúrese de configurar los roles de aplicación correctamente para el escenario de acceso previsto. Si tiene la intención de que los roles de aplicación de la API se usen para el acceso de solo aplicación, seleccione las aplicaciones como los únicos tipos de miembros permitidos al crear los roles de aplicación.
¿Cómo funciona el acceso de solo aplicación?
Lo más importante que hay que recordar sobre el acceso de solo aplicación es que la aplicación que realiza la llamada actúa en su propio nombre y como su propia identidad. No hay interacción del usuario. Si la aplicación se ha asignado a un rol de aplicación determinado para un recurso, la aplicación tiene acceso sin ningún tipo de restricciones a todos los recursos y operaciones que se rigen por ese rol de aplicación.
Una vez que se haya asignado una aplicación a uno o varios roles de aplicación (permisos de solo aplicación), puede solicitar un token de solo aplicación de Microsoft Entra ID mediante el flujo de credenciales de cliente o cualquier otro flujo de autenticación admitido. Los roles asignados se agregan a la notificación roles del token de acceso de la aplicación.
En algunos escenarios, la identidad de la aplicación puede determinar si se concede acceso, de forma similar a los permisos del usuario en una llamada delegada. Por ejemplo, el rol de aplicación Application.ReadWrite.OwnedBy concede a una aplicación la capacidad de administrar las entidades de servicio que posee la propia aplicación.
Ejemplo de acceso de solo aplicación: notificación de correo electrónico automatizada a través de Microsoft Graph
En el ejemplo siguiente se muestra un escenario de automatización realista.
Alice quiere notificar a un equipo por correo electrónico cada vez que la carpeta de informes de división que reside en un recurso compartido de archivos de Windows registra un nuevo documento. Alice crea una tarea programada que ejecuta un script de PowerShell para examinar la carpeta y buscar nuevos archivos. A continuación, el script envía un correo electrónico mediante un buzón protegido por una API de recursos, Microsoft Graph.
El script se ejecuta sin ninguna interacción del usuario, por lo que el sistema de autorización solo comprueba la autorización de la aplicación. Exchange Online comprueba si el administrador ha concedido al cliente que realiza la llamada el permiso de aplicación (rol de aplicación), Mail.Send. Si Mail.Send no se concede a la aplicación, Exchange Online genera un error en la solicitud.
| POST /users/{id}/{userPrincipalName}/sendMail | La aplicación cliente ha concedido Mail.Send | La aplicación cliente no ha concedido Mail.Send |
|---|---|---|
| El script usa el buzón de Alice para enviar correos electrónicos. | 200: Acceso concedido. El administrador ha permitido a la aplicación enviar correos como cualquier usuario. | 403: No autorizado. El administrador no ha permitido a este cliente enviar correos electrónicos. |
| El script crea un buzón dedicado para enviar correos electrónicos. | 200: Acceso concedido. El administrador ha permitido a la aplicación enviar correos como cualquier usuario. | 403: No autorizado. El administrador no ha permitido a este cliente enviar correos electrónicos. |
El ejemplo proporcionado es una ilustración sencilla de la autorización de la aplicación. El servicio de Exchange Online de producción admite muchos otros escenarios de acceso, como la limitación de los permisos de aplicación a buzones de Exchange Online específicos.