Compartir a través de

Información general sobre los permisos y el consentimiento en la Plataforma de identidad de Microsoft

En la plataforma de identidad de Microsoft, comprender los permisos y el consentimiento es fundamental para desarrollar aplicaciones seguras que requieren acceso a los recursos protegidos. En este artículo se proporciona información general sobre los conceptos básicos y los escenarios relacionados con los permisos y el consentimiento, lo que ayuda a los desarrolladores de aplicaciones a solicitar las autorizaciones necesarias de los usuarios y administradores. Al comprender estos conceptos, puede asegurarse de que las aplicaciones solo solicitan el acceso que necesitan, fomentando la confianza y la seguridad.

Para acceder a un recurso protegido, como el correo electrónico o los datos del calendario, la aplicación necesita la autorización del propietario del recurso. El propietario del recurso puede dar su consentimiento o rechazar la solicitud hecha por la aplicación. Comprender estos conceptos fundamentales le ayuda a crear aplicaciones más seguras y de confianza que solicitan solo el acceso que necesitan, cuando lo necesitan, de usuarios y administradores.

Escenarios de acceso

Como desarrollador de aplicaciones, debe identificar cómo la aplicación accede a los datos. La aplicación puede usar el acceso delegado, actuar en nombre de un usuario que ha iniciado sesión o el acceso solo a la aplicación, actuando solo como identidad propia de la aplicación.

Imagen que muestra la ilustración de escenarios de acceso.

Acceso delegado (acceso en nombre de un usuario)

En este escenario de acceso, un usuario ha iniciado sesión en una aplicación cliente. La aplicación cliente accede al recurso en nombre del usuario. El acceso delegado requiere permisos delegados. Tanto el cliente como el usuario deben estar autorizados por separado para realizar la solicitud. Para obtener más información sobre el escenario de acceso delegado, consulte escenario de acceso delegado.

Para la aplicación cliente, se deben conceder los permisos delegados correctos. Los permisos delegados también se pueden denominar ámbitos. Los ámbitos son permisos para un recurso determinado que representan a qué puede acceder una aplicación cliente en nombre del usuario. Para obtener más información sobre los ámbitos, consulte ámbitos y permisos.

Para el usuario, la autorización se basa en los privilegios concedidos al usuario para que accedan al recurso. Por ejemplo, el usuario podría estar autorizado para acceder a los recursos de directorio mediante el control de acceso basado en rol (RBAC) de Microsoft Entra o para acceder a los recursos de correo y calendario mediante RBAC de Exchange Online. Para obtener más información sobre RBAC para aplicaciones, consulte RBAC para aplicaciones.

Acceso solo a la aplicación (acceso sin un usuario)

En este escenario de acceso, la aplicación actúa por sí misma sin que ningún usuario haya iniciado sesión. El acceso de aplicación se usa en escenarios como la automatización y la copia de seguridad. Por ejemplo, las aplicaciones que se ejecutan como servicios en segundo plano o demonios. Es adecuado cuando no es conveniente que un usuario específico haya iniciado sesión o cuando los datos necesarios no se puedan limitar a un solo usuario. Para obtener más información sobre el escenario de acceso de solo aplicación, consulte acceso solo a la aplicación.

El acceso de solo aplicación usa roles de aplicación en lugar de ámbitos delegados. Cuando se concede a través del consentimiento, es posible que los roles de aplicación también se llamen permisos de aplicaciones. A la aplicación cliente se le deben conceder los permisos de aplicación adecuados de la aplicación de recursos a la que llama. Una vez concedido, la aplicación cliente puede acceder a los datos solicitados. Para obtener más información sobre cómo asignar roles de aplicación a aplicaciones cliente, consulte Asignar roles de aplicación para aplicaciones.

Tipos de permisos

Los permisos delegados se usan en el escenario de acceso delegado. Son permisos que permiten a la aplicación actuar en nombre de un usuario. La aplicación no puede acceder a nada al que el usuario que ha iniciado sesión no pudo acceder.

Por ejemplo, tome una aplicación a la que se concede el Files.Read.All permiso delegado en nombre del usuario. La aplicación solo puede leer archivos a los que el usuario puede acceder personalmente.

Permisos de aplicación, también conocidos como roles de aplicación, se usan en el escenario de acceso de solo aplicación, sin que haya un usuario que haya iniciado sesión. La aplicación puede acceder a los datos a los que está asociado el permiso.

Por ejemplo, una aplicación concedida el permiso de aplicación Files.Read.All para la API de Microsoft Graph puede leer cualquier archivo del arrendatario mediante la API de Microsoft Graph. En general, solo un administrador o propietario de la entidad de servicio de una API puede dar su consentimiento a los permisos de aplicación expuestos por esa API.

Comparación de permiso de aplicación y delegados

Tipos de permisos Permisos delegados Permisos de aplicación
Tipos de aplicaciones Aplicación web/móvil/de página única (SPA) Web/Demonio
Contexto de acceso Obtención del acceso en nombre de un usuario Obtener acceso sin un usuario
¿Quién puede dar el consentimiento? - Los usuarios pueden dar su consentimiento para sus datos
- Los administradores pueden dar su consentimiento para todos los usuarios		 Solo el administrador puede dar consentimiento a
Métodos de consentimiento - Estático: lista configurada en el registro de aplicaciones
- Dinámico: solicitar permisos individuales en el inicio de sesión		 - SOLO estático: lista configurada en el registro de aplicaciones
Otros nombres - Ámbitos
- Ámbitos de permiso de OAuth2		 - Roles de aplicación
- Permisos solo de aplicación
Resultado del consentimiento (específico de Microsoft Graph) OAuth2PermissionGrant appRoleAssignment

Una manera en que se conceden permisos a las aplicaciones es a través del consentimiento. El consentimiento es un proceso en el que los usuarios o administradores autorizan a una aplicación el acceso a un recurso protegido. Por ejemplo, cuando un usuario intenta iniciar sesión por primera vez en una aplicación, la aplicación puede solicitar permiso para ver el perfil del usuario y leer el contenido del buzón del usuario. El usuario ve la lista de permisos que la aplicación solicita a través de un mensaje de consentimiento. Otros escenarios en los que los usuarios pueden ver un mensaje de consentimiento incluyen:

  • Cuando se revoca el consentimiento concedido previamente.
  • Cuando la aplicación se codifica para solicitar específicamente el consentimiento durante el inicio de sesión.
  • Cuando la aplicación usa el consentimiento dinámico para solicitar nuevos permisos según sea necesario en el entorno de ejecución.

Los detalles clave de un mensaje de consentimiento son la lista de permisos que requiere la aplicación y la información del publicador. Para obtener más información sobre la solicitud de consentimiento y la experiencia de consentimiento para los administradores y los usuarios finales, consulte experiencia de consentimiento de la aplicación.

El consentimiento del usuario se produce cuando un usuario intenta iniciar sesión en una aplicación. El usuario proporciona sus credenciales de inicio de sesión, que se comprueban para determinar si ya se concede el consentimiento. Si no existe ningún registro anterior de consentimiento del usuario o administrador para los permisos necesarios, se muestra al usuario una solicitud de consentimiento y se le pide que conceda a la aplicación los permisos solicitados. Es posible que sea necesario que un administrador conceda consentimiento en nombre del usuario.

Dependiendo de los permisos que se necesiten, es posible que algunas aplicaciones requieran que un administrador sea el que conceda consentimiento. Por ejemplo, los permisos de aplicación y muchos permisos delegados de alto privilegio solo se pueden conceder por un administrador.

Los administradores pueden conceder consentimiento para sí mismos o para toda la organización. Para más información sobre el consentimiento del usuario y del administrador, consulte la información general sobre el consentimiento del usuario y el administrador.

Se solicitan solicitudes de autenticación para el consentimiento del administrador si no se concedió el consentimiento y si se solicita uno de los permisos de privilegios elevados.

Las solicitudes de permisos que contienen ámbitos de aplicación personalizados no se consideran privilegios elevados y, por lo tanto, no requieren consentimiento del administrador.

Autorización previa

La autenticación previa permite que un propietario de la aplicación de recursos conceda permisos sin necesidad de que los usuarios vean un aviso de consentimiento para el mismo conjunto de permisos que están autenticados previamente. De este modo, una aplicación previamente autenticada no pide a los usuarios que consienten los permisos. Los propietarios de recursos pueden autenticar previamente las aplicaciones cliente en Azure Portal o mediante PowerShell y las API como Microsoft Graph.

En la mayoría de los casos, las aplicaciones orientadas al cliente en el identificador externo de Microsoft Entra requerirán la autenticación previa, ya que están pensadas para los usuarios que no forman parte de la organización y que no podrán dar su consentimiento a los permisos solicitados por la aplicación. La autenticación previa garantiza que estos usuarios puedan acceder a la aplicación sin que se le pida consentimiento.

Otros sistemas de autorización

El marco de consentimiento es solo una manera en que una aplicación o usuario puede estar autorizado para acceder a los recursos protegidos. Los administradores deben tener en cuenta otros sistemas de autorización que pueden conceder acceso a información confidencial. Entre los ejemplos de varios sistemas de autorización de Microsoft se incluyen roles integrados de Microsoft Entra, RBAC de Azure, RBAC de Exchange y consentimiento específico del recurso de Teams.

Consulte también

  • Last updated on