Compartir vía

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

  • Artículo

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 denegar la solicitud de la aplicación. Comprender estos conceptos básicos te ayudará a crear aplicaciones más seguras y confiables 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 accederá la aplicación 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 solo a la aplicación, consulta Acceso solo a través de 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, los roles de aplicación también se pueden denominar 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 nunca podrá acceder a nada a lo que los usuarios que han iniciado sesión no puedan acceder.

Por ejemplo, tome una aplicación a la que se le haya concedido el permiso delegado Files.Read.All en nombre del usuario. La aplicación solo podrá leer archivos a los que el usuario pueda 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 podrá acceder a los datos a los que está asociado el permiso.

Por ejemplo, una aplicación conceda el permiso de aplicación de Microsoft Graph API Files.Read.All podrá leer cualquier archivo del inquilino mediante 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 administradores y usuarios finales, consulte la 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 ha concedido 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 autorización previa permite que un propietario de la aplicación de recursos conceda permisos sin necesidad de que los usuarios vean un mensaje de consentimiento para el mismo conjunto de permisos que se han autorizado previamente. De este modo, una aplicación que se ha autenticado previamente no pedirá a los usuarios que concedan su consentimiento a los permisos. Los propietarios de recursos pueden autorizar previamente las aplicaciones cliente en Azure Portal o mediante PowerShell y las API, como Microsoft Graph.

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 Entra, RBAC de Azure, RBAC de Exchangey consentimiento específico del recurso de Teams.

Consulte también