Básicos de autenticación y autorización
Microsoft Graph es una puerta de enlace de API protegida para acceder a datos en servicios en la nube de Microsoft, como Microsoft Entra ID y Microsoft 365. Está protegida por el Plataforma de identidad de Microsoft, que autoriza y comprueba que una aplicación está autorizada para llamar a Microsoft Graph.
En este artículo se proporciona información general sobre los requisitos para que una aplicación tenga autorización para acceder a los datos a través de cualquier Graph API de Microsoft. Si ya está familiarizado con cómo funciona la autenticación y la autorización, explore Plataforma de identidad de Microsoft ejemplos de código o tutoriales de Microsoft Graph para aplicaciones compiladas con diferentes SDK de Microsoft Graph y que llamen a las API de Microsoft Graph.
Registrar la aplicación
Antes de que se pueda autorizar a la aplicación para llamar a cualquier Graph API de Microsoft, el Plataforma de identidad de Microsoft primero debe tenerla en cuenta. Este proceso no implica cargar el código de la aplicación en la plataforma. En su lugar, implica registrar la aplicación en el Centro de administración Microsoft Entra para establecer su información de configuración, incluidos los siguientes parámetros principales:
- Id. de aplicación: un identificador único que asigna la plataforma de identidad de Microsoft.
- URI o DIRECCIÓN URL de redireccionamiento: uno o varios puntos de conexión en los que la aplicación recibe respuestas de la Plataforma de identidad de Microsoft. El Plataforma de identidad de Microsoft asigna el URI a aplicaciones nativas y móviles.
- Credencial: puede ser un secreto de cliente (una cadena o contraseña), un certificado o una credencial de identidad federada. La aplicación usa la credencial para autenticarse con el Plataforma de identidad de Microsoft. Esta propiedad solo es necesaria para aplicaciones cliente confidenciales; No es necesario para clientes públicos como aplicaciones nativas, móviles y de página única. Para obtener más información, consulte Aplicaciones cliente pública y cliente confidencial.
A continuación, vuelve a agregar esta información al código una vez y la aplicación usa la información cada vez que es necesario demostrar su identidad durante un proceso de autenticación, antes de que se pueda autorizar para acceder a los datos.
Para obtener más información, consulte Registro de una aplicación con el Plataforma de identidad de Microsoft.
Escenarios de acceso
Una aplicación puede acceder a los datos de una de estas dos maneras, como se muestra en la siguiente imagen.
- Acceso delegado, una aplicación que actúa en nombre de un usuario que ha iniciado sesión.
- Acceso solo a la aplicación, una aplicación que actúa con su propia identidad.
Acceso delegado (acceso en nombre de un usuario)
En este escenario de acceso, un usuario inicia sesión en una aplicación cliente que llama a Microsoft Graph en nombre de su nombre. Tanto la aplicación cliente como el usuario deben estar autorizados para realizar la solicitud.
Para que la aplicación cliente tenga autorización para acceder a los datos en nombre del usuario que ha iniciado sesión, debe tener los permisos necesarios, que recibe a través de una combinación de dos factores:
- Permisos delegados, también conocidos como ámbitos: los permisos expuestos por Microsoft Graph y que representan las operaciones que la aplicación puede realizar en nombre del usuario que ha iniciado sesión. Es posible que la aplicación pueda realizar una operación en nombre de un usuario, pero no de otro.
- Permisos de usuario: los permisos que tiene el usuario que ha iniciado sesión en el recurso. Es posible que el usuario sea el propietario del recurso, que el recurso se comparta con él o que se le asignen permisos a través de un sistema de control de acceso basado en rol (RBAC), como Microsoft Entra RBAC.
Escenario de ejemplo: Acceso delegado en Microsoft Graph
El https://graph.microsoft.com/v1.0/me punto de conexión es el punto de acceso a la información del usuario que ha iniciado sesión, que representa un recurso protegido por el Plataforma de identidad de Microsoft. Para el acceso delegado, los dos factores se cumplen de la siguiente manera:
- Se debe conceder a la aplicación un permiso delegado de Microsoft Graph compatible, por ejemplo, el permiso delegado User.Read , en nombre del usuario que ha iniciado sesión.
- El usuario que ha iniciado sesión en este escenario es el propietario de los datos.
Nota:
Los puntos de conexión y las API con el /me alias solo funcionan en el usuario que ha iniciado sesión y, por tanto, se llaman en escenarios de acceso delegado.
Como alternativa a los permisos delegados de Microsoft Graph, también se pueden asignar permisos a una aplicación a través de un sistema de control de acceso basado en rol, como Microsoft Entra RBAC.
Acceso solo a la aplicación (acceso sin un usuario)
En este escenario de acceso, la aplicación puede interactuar con los datos por sí sola, sin que un usuario haya iniciado sesión. El acceso solo a la aplicación se usa en escenarios como la automatización y la copia de seguridad, y lo usan principalmente las aplicaciones que se ejecutan como servicios en segundo plano o demonios. Es adecuado cuando no es conveniente que un usuario haya iniciado sesión o cuando los datos necesarios no se puedan limitar a un solo usuario.
Para que una aplicación cliente tenga autorización para acceder a los datos con su propia identidad, debe tener los permisos necesarios, que recibe de una de las siguientes maneras:
- A la aplicación se le asignan permisos de aplicación de Microsoft Graph admitidos, también denominados roles de aplicación.
- A la aplicación se le asigna la propiedad del recurso que pretende administrar.
Nota:
Como alternativa a los permisos de aplicación de Microsoft Graph, también se pueden asignar permisos a una aplicación a través de un sistema de control de acceso basado en rol, como Microsoft Entra RBAC.
Escenario de ejemplo: acceso solo a la aplicación en Microsoft Graph
El https://graph.microsoft.com/v1.0/users/delta punto de conexión permite sondear los cambios en los datos del usuario. En el acceso solo a la aplicación, se debe conceder a la aplicación un permiso compatible, por ejemplo, el permiso de aplicación User.Read.All de Microsoft Graph para poder consultar y recibir correctamente los cambios en los datos de usuario.
Permisos de Microsoft Graph
Como se mencionó anteriormente, una aplicación debe tener permisos para acceder a los datos a los que quiere acceder, independientemente del escenario de acceso.
Microsoft Graph expone permisos granulares que controlan el acceso a los recursos de Microsoft Graph, como usuarios, grupos y correo. Hay dos tipos de permisos disponibles para los escenarios de acceso admitidos:
- Permisos delegados: también denominados ámbitos, permiten que la aplicación actúe en nombre del usuario que ha iniciado sesión.
- Permisos de aplicación: también denominados roles de aplicación, permite que la aplicación acceda a los datos por sí sola, sin que un usuario haya iniciado sesión.
Como desarrollador, decide qué permisos de Microsoft Graph se van a solicitar para la aplicación en función del escenario de acceso y las operaciones que quiera realizar. Cuando un usuario inicia sesión en una aplicación, la aplicación debe especificar los permisos que debe incluir en el token de acceso. Estos permisos:
- Puede ser preautorizado para la aplicación por un administrador.
- El usuario puede dar su consentimiento directamente.
- Si no está autorizado previamente, puede requerir privilegios de administrador para conceder consentimiento. Por ejemplo, para permisos con un mayor impacto potencial en la seguridad.
Para obtener más información sobre los permisos y el consentimiento, consulte Introducción a los permisos y el consentimiento.
Para obtener más información sobre los permisos de Microsoft Graph y cómo usarlos, consulte información general sobre los permisos de Microsoft Graph.
Nota:
El procedimiento recomendado es solicitar los permisos con menos privilegios que necesita la aplicación para acceder a los datos y funcionar correctamente. Solicitar permisos con más privilegios de los necesarios es una mala práctica de seguridad que puede hacer que los usuarios se abstengan de dar su consentimiento y que afecten al uso de la aplicación.
Tokens de acceso
Para acceder a un recurso protegido, una aplicación debe demostrar que está autorizada para hacerlo mediante el envío de un token de acceso válido. La aplicación obtiene este token de acceso cuando realiza una solicitud de autenticación al Plataforma de identidad de Microsoft que, a su vez, usa el token de acceso para comprobar que la aplicación está autorizada para llamar a Microsoft Graph.
Los tokens de acceso que el Plataforma de identidad de Microsoft problemas contienen notificaciones que son detalles sobre la aplicación y en escenarios de acceso delegado, el usuario que ha iniciado sesión. Las API web, como Microsoft Graph, protegidas por el Plataforma de identidad de Microsoft usan las notificaciones para validar al autor de la llamada y para asegurarse de que el autor de la llamada está autorizado para realizar la operación que solicita. En el caso de los escenarios de acceso delegado, los permisos del usuario que realiza la llamada y de la aplicación forman parte de las notificaciones. En escenarios de aplicación, los permisos de la aplicación forman parte de las notificaciones. Para obtener más información sobre las piezas que constituyen tokens de acceso, consulte Referencia de notificaciones de token de acceso.
Para llamar a Microsoft Graph, la aplicación realiza una solicitud de autorización adjuntando el token de acceso como token de portador al encabezado Authorization en una solicitud HTTP. Por ejemplo, a continuación se muestra una llamada que devuelve la información de perfil del usuario que ha iniciado sesión (el token de acceso se ha acortado para mejorar la legibilidad):
GET https://graph.microsoft.com/v1.0/me/ HTTP/1.1
Host: graph.microsoft.com
Authorization: Bearer EwAoA8l6BAAU ... 7PqHGsykYj7A0XqHCjbKKgWSkcAg==
Para más información sobre Plataforma de identidad de Microsoft tokens de acceso, consulte Tokens de identificador en el Plataforma de identidad de Microsoft.
Obtener un token de acceso
Se recomienda usar bibliotecas de autenticación para administrar las interacciones de token con el Plataforma de identidad de Microsoft. Las bibliotecas de autenticación abstraen muchos detalles de protocolo, como la validación, el control de cookies, el almacenamiento en caché de tokens y el mantenimiento de conexiones seguras, lo que permite centrar el desarrollo en la funcionalidad de la aplicación. Microsoft publica bibliotecas de cliente de código abierto y middleware de servidor.
Para el punto de conexión de la Plataforma de identidad de Microsoft:
- Las bibliotecas cliente de la Biblioteca de autenticación de Microsoft (MSAL) están disponibles para varios marcos, incluidos .NET, JavaScript, Android e iOS. Todas las plataformas están en versión preliminar compatible con producción y, en caso de que se introduzcan cambios importantes, Microsoft garantiza una ruta de actualización.
- El middleware de servidor de Microsoft está disponible para .NET Core y ASP.NET (OWIN OpenID Connect y OAuth) y para Node.js (Plataforma de identidad de Microsoft Passport.js).
- El Plataforma de identidad de Microsoft también es compatible con muchas bibliotecas de autenticación de terceros.
Para obtener una lista completa de las bibliotecas cliente de Microsoft, el middleware de servidor de Microsoft y las bibliotecas compatibles de terceros, consulte Plataforma de identidad de Microsoft documentación.
También puede usar los puntos de conexión de Plataforma de identidad de Microsoft directamente sin la ayuda de una biblioteca de autenticación. Para más información, consulte los siguientes artículos: