Introducción a los permisos y el consentimiento

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 fundamentales le ayudará a crear aplicaciones más seguras y de confianza que soliciten solo el acceso que necesitan, cuando lo necesitan, de sus 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 la sección acerca de á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 Azure Active Directory (Azure AD) 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.

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. Para el acceso de solo aplicación, se debe conceder a la aplicación cliente los roles de aplicación adecuados de la aplicación de recursos a la que llama para 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, imagine una aplicación a la que se ha concedido el permiso delegado Files.Read.All en nombre de Tom, el usuario. La aplicación solo podrá leer archivos a los que Tom puede acceder personalmente.

Los permisos de aplicación, en ocasiones denominados roles de aplicación, se usan en el escenario de acceso solo a la 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 a la que se le haya concedido el permiso Files.Read.All podrá leer cualquier archivo del inquilino. Solo un administrador o propietario de la entidad de servicio puede dar su consentimiento a los permisos de aplicación.

Hay otras maneras en las que se puede conceder autorización a las aplicaciones para el acceso solo a la aplicación. Por ejemplo, se puede asignar a una aplicación un rol RBAC de Azure AD.

Comparación de permiso de aplicación y delegados

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 cada 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. Estas credenciales 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. En muchos casos, puede ser necesario que un administrador otorgue el 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.

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.

Pasos siguientes