Descripción del acceso delegado
Cuando un usuario inicia sesión en una aplicación y la usa para acceder a algún otro recurso, como Microsoft Graph, la aplicación primero tendrá que solicitar permiso para acceder a este recurso en nombre del usuario. Este escenario común se denomina acceso delegado.
¿Por qué debo usar el acceso delegado?
Las personas usan con frecuencia diferentes aplicaciones para acceder a sus datos en servicios en la nube. Por ejemplo, es posible que alguien quiera usar su aplicación para leer PDF favorita para ver los archivos almacenados en su OneDrive. Otro ejemplo puede ser la aplicación de línea de negocio de una empresa que podría recuperar información compartida sobre sus compañeros de trabajo para que puedan elegir fácilmente revisores para una solicitud. En tales casos, la aplicación cliente, el lector de PDF o la herramienta de aprobación de solicitudes de la empresa deben estar autorizadas para acceder a estos datos en nombre del usuario que inició sesión en la aplicación.
Use el acceso delegado siempre que quiera permitir que un usuario que haya iniciado sesión trabaje con sus propios recursos o recursos a los que pueda acceder. Tanto si es un administrador que configura directivas para toda su organización como un usuario que elimina un correo electrónico en su bandeja de entrada, todos los escenarios que implican acciones de usuario deben usar el acceso delegado.
Por el contrario, el acceso delegado suele ser una mala opción para escenarios que se deben ejecutar sin un usuario que haya iniciado sesión, como la automatización. También puede ser una mala opción para escenarios que impliquen el acceso a muchos recursos de los usuarios, como la prevención de pérdida de datos o las copias de seguridad. Considere la posibilidad de usar el acceso aplicación solamente para estos tipos de operaciones.
Solicitud de ámbitos como una aplicación cliente
La aplicación deberá pedir al usuario que conceda un ámbito específico o un conjunto de ámbitos para la aplicación de recursos a la que quiere acceder. Los ámbitos también se pueden denominar permisos delegados. Estos ámbitos describen qué recursos y operaciones quiere realizar la aplicación en nombre del usuario. Por ejemplo, si quiere que la aplicación muestre al usuario una lista de mensajes de correo y mensajes de chat recibidos recientemente, puede pedir al usuario que dé su consentimiento a los ámbitos Mail.Read y Chat.Read de Microsoft Graph.
Una vez que la aplicación haya solicitado un ámbito, un usuario o administrador deberá conceder el acceso solicitado. Los usuarios consumidores con cuentas de Microsoft, como Outlook.com o cuentas de Xbox Live, siempre pueden conceder ámbitos para sí mismos. Los usuarios de la organización con cuentas de Microsoft Entra pueden o no ser capaces de conceder ámbitos en función de la configuración de su organización. Si un usuario de la organización no puede dar su consentimiento directamente a los ámbitos, deberá pedir al administrador de su organización que dé su consentimiento.
Siga siempre el principio de privilegios mínimos: nunca debe solicitar ámbitos 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 enumerar los chats a los que pertenece un usuario, pero no necesita mostrar los propios mensajes de chat, debe solicitar el ámbito Chat.ReadBasic de Microsoft Graph más limitado en lugar de Chat.Read. Para obtener más información sobre los ámbitos openID, consulte Ámbitos OpenID.
Diseño y publicación de ámbitos para un servicio de recursos
Si va a crear una API y quiere permitir el acceso delegado en nombre de los usuarios, deberá crear ámbitos que otras aplicaciones puedan solicitar. Estos ámbitos deben describir las acciones o los recursos disponibles para el cliente. Debe tener en cuenta los escenarios de desarrollador al diseñar los ámbitos.
Token a sí mismo
En el escenario donde:
- La aplicación de recursos y la aplicación cliente son las mismas.
- La aplicación no tiene ninguna API web registrada.
- La aplicación solicita un token para un permiso delegado que se expone a sí mismo
No se necesitará ningún consentimiento ni se mostrará para esta solicitud de token. Además, se puede deducir que las aplicaciones que se crean dentro de un inquilino y solicitan un token para sí mismas ya tienen acceso a los datos del perfil, y se les concederá acceso al perfil automáticamente.
¿Cómo funciona el acceso delegado?
Lo más importante que hay que recordar sobre el acceso delegado es que tanto la aplicación cliente como el usuario que ha iniciado sesión deben estar autorizados correctamente. La concesión de un ámbito no es suficiente. Si la aplicación cliente no tiene el ámbito correcto o el usuario no tiene derechos suficientes para leer o modificar el recurso, se producirá un error en la llamada.
- Autorización de aplicaciones cliente: se autoriza a las aplicaciones cliente mediante la concesión de ámbitos. Cuando un usuario o administrador concede un ámbito a una aplicación cliente para acceder a algún recurso, esa concesión se registrará en el Id. de Microsoft Entra. Todos los tokens de acceso delegado solicitados por el cliente para acceder al recurso en nombre del usuario correspondiente contendrán los valores de notificación de esos ámbitos en la notificación
scp. La aplicación de recursos comprueba esta notificación para determinar si a la aplicación cliente se le ha concedido el ámbito correcto para la llamada. - Autorización de usuario: se autoriza a los usuarios por el recurso al que llama. Las aplicaciones de recursos pueden usar uno o varios sistemas para la autorización de usuarios, como el control de acceso basado en roles, las relaciones de propiedad o pertenencia, las listas de control de acceso u otras comprobaciones. Por ejemplo, el Id. de Microsoft Entra comprueba que un usuario se ha asignado a una administración de aplicaciones o a un rol de administrador general antes de permitirle eliminar las aplicaciones de una organización, pero también permite a todos los usuarios eliminar las aplicaciones que poseen. Del mismo modo, el servicio SharePoint Online comprueba que un usuario tiene derechos de propietario o lector adecuados sobre un archivo antes de permitir que ese usuario lo abra.
Ejemplo de acceso delegado: OneDrive a través de Microsoft Graph
Considere el ejemplo siguiente:
Alice quiere usar una aplicación cliente para abrir un archivo protegido por una API de recursos, Microsoft Graph. Para la autorización del usuario, el servicio OneDrive comprobará si el archivo se almacena en la unidad de Alice. Si se almacena en la unidad de otro usuario, OneDrive denegará la solicitud de Alice como no autorizada, ya que Alice no tiene derecho a leer las unidades de otros usuarios.
En el caso de la autorización de la aplicación cliente, OneDrive comprobará si se ha concedido al cliente que realiza la llamada el ámbito Files.Read en nombre del usuario que ha iniciado sesión. En este caso, el usuario que ha iniciado sesión es Alice. Si Files.Read no se ha concedido a la aplicación para Alice, OneDrive también producirá un error en la solicitud.
| GET /drives/{id}/files/{id} | Ámbito Files.Read concedido a la aplicación cliente para Alice |
Ámbito Files.Read no concedido a la aplicación cliente para Alice |
|---|---|---|
| El documento está en OneDrive de Alice. | 200: Acceso concedido. | 403: No autorizado. Alice (o su administrador) no ha permitido que este cliente lea sus archivos. |
| El documento está en OneDrive* de otro usuario. | 403: No autorizado. Alice no tiene derechos para leer este archivo. Aunque se le haya concedido Files.Read al cliente, debe denegarse cuando actúe en nombre de Alice. |
403: No autorizado. Alice no tiene derechos para leer este archivo y el cliente no puede leer los archivos a los que ella tiene acceso. |
El ejemplo se ha simplificado para ilustrar la autorización delegada. El servicio OneDrive de producción admite muchos otros escenarios de acceso, como archivos compartidos.