Partager via

Informations de base sur l’authentification et l’autorisation

  • Article

Microsoft Graph est une passerelle API protégée pour l’accès aux données dans les services cloud Microsoft comme Microsoft Entra ID et Microsoft 365. Il est protégé par le Plateforme d'identités Microsoft, qui autorise et vérifie qu’une application est autorisée à appeler Microsoft Graph.

Cet article fournit une vue d’ensemble des conditions requises pour qu’une application soit autorisée à accéder aux données via n’importe quel API Graph Microsoft. Si vous êtes déjà familiarisé avec le fonctionnement de l’authentification et de l’autorisation, explorez Plateforme d'identités Microsoft exemples de code ou des tutoriels Microsoft Graph pour les applications créées à l’aide de différents sdk Microsoft Graph et qui appellent des API Microsoft Graph.

Inscription de l’application

Avant que votre application puisse être autorisée à appeler des API Graph Microsoft, le Plateforme d'identités Microsoft doit d’abord en être conscient. Ce processus n’implique pas le chargement du code de votre application sur la plateforme. Au lieu de cela, il s’agit d’inscrire l’application dans le centre d’administration Microsoft Entra pour établir ses informations de configuration, y compris les paramètres de base suivants :

  • ID de l’application : identifiant unique attribué par la Plateforme d’identités Microsoft.
  • URI/URL de redirection : un ou plusieurs points de terminaison auxquels votre application reçoit des réponses de la Plateforme d'identités Microsoft. Le Plateforme d'identités Microsoft attribue l’URI aux applications natives et mobiles.
  • Informations d’identification : il peut s’agir d’une clé secrète client (chaîne ou mot de passe), d’un certificat ou d’informations d’identification d’identité fédérée. Votre application utilise les informations d’identification pour s’authentifier auprès du Plateforme d'identités Microsoft. Cette propriété est requise uniquement pour les applications clientes confidentielles ; Il n’est pas obligatoire pour les clients publics tels que les applications natives, mobiles et monopage. Pour plus d’informations, consultez Applications clientes publiques et clientes confidentielles.

Vous rajoutez ensuite ces informations à votre code une fois, et l’application utilise les informations chaque fois qu’elle doit prouver son identité au cours d’un processus d’authentification, avant de pouvoir être autorisée à accéder à vos données.

Pour plus d’informations, consultez Inscrire une application avec le Plateforme d'identités Microsoft.

Scénarios d’accès

Une application peut accéder aux données de l’une des deux manières suivantes, comme illustré dans l’image suivante.

  • Accès délégué, une application agissant pour le compte d’un utilisateur connecté.
  • Accès à l’application uniquement, une application agissant avec sa propre identité.

Illustration des scénarios d’accès délégué et d’application uniquement dans le Plateforme d'identités Microsoft.

Accès délégué (accès au nom d’un utilisateur)

Dans ce scénario d’accès, un utilisateur se connecte à une application cliente qui appelle Microsoft Graph en son nom. L’application cliente et l’utilisateur doivent être autorisés à effectuer la demande.

Pour que l’application cliente soit autorisée à accéder aux données au nom de l’utilisateur connecté, elle doit disposer des autorisations requises, qu’elle reçoit grâce à une combinaison de deux facteurs :

  • Autorisations déléguées, également appelées étendues : autorisations exposées par Microsoft Graph et qui représentent les opérations que l’application peut effectuer pour le compte de l’utilisateur connecté. L’application peut être autorisée à effectuer une opération pour le compte d’un utilisateur, mais pas d’un autre.
  • Autorisations utilisateur : autorisations dont dispose l’utilisateur connecté sur la ressource. L’utilisateur peut être le propriétaire de la ressource, la ressource peut être partagée avec lui ou des autorisations peuvent lui être attribuées via un système de contrôle d’accès en fonction du rôle (RBAC) tel que Microsoft Entra RBAC.

Exemple de scénario : Accès délégué dans Microsoft Graph

Le https://graph.microsoft.com/v1.0/me point de terminaison est le point d’accès aux informations de l’utilisateur connecté, qui représente une ressource protégée par le Plateforme d'identités Microsoft. Pour l’accès délégué, les deux facteurs sont remplis comme suit :

  • L’application doit disposer d’une autorisation déléguée Microsoft Graph prise en charge, par exemple l’autorisation déléguée User.Read , au nom de l’utilisateur connecté.
  • L’utilisateur connecté dans ce scénario est le propriétaire des données.

Remarque

Les points de terminaison et les API avec l’alias /me fonctionnent uniquement sur l’utilisateur connecté et sont donc appelés dans les scénarios d’accès délégué.

En guise d’alternative aux autorisations déléguées Microsoft Graph, une application peut également se voir attribuer des autorisations par le biais d’un système de contrôle d’accès en fonction du rôle tel que Microsoft Entra RBAC.

Accès aux applications uniquement (accès sans utilisateur)

Dans ce scénario d’accès, l’application peut interagir avec les données seule, sans utilisateur connecté. L’accès aux applications uniquement est utilisé dans des scénarios tels que l’automatisation et la sauvegarde, et est principalement utilisé par les applications qui s’exécutent en tant que services ou démons en arrière-plan. Il convient lorsqu’il n’est pas souhaitable qu’un utilisateur se connecte ou que les données requises ne peuvent pas être étendues à un seul utilisateur.

Pour qu’une application cliente soit autorisée à accéder aux données avec sa propre identité, elle doit disposer des autorisations requises, qu’elle reçoit de l’une des manières suivantes :

  • L’application se voit attribuer des autorisations d’application Microsoft Graph prises en charge, également appelées rôles d’application
  • L’application se voit attribuer la propriété de la ressource qu’elle a l’intention de gérer

Remarque

En guise d’alternative aux autorisations d’application Microsoft Graph, une application peut également se voir attribuer des autorisations via un système de contrôle d’accès en fonction du rôle tel que Microsoft Entra RBAC.

Exemple de scénario : Accès aux applications uniquement dans Microsoft Graph

Le https://graph.microsoft.com/v1.0/users/delta point de terminaison vous permet d’interroger les modifications apportées aux données utilisateur. Dans l’accès à l’application uniquement, une autorisation prise en charge doit être accordée à l’application, par exemple l’autorisation d’application Microsoft Graph User.Read.All pour pouvoir interroger et recevoir correctement les modifications apportées aux données utilisateur.

Autorisations de Microsoft Graph

Comme mentionné précédemment, une application doit disposer des autorisations nécessaires pour accéder aux données auxquelles elle souhaite accéder, quel que soit le scénario d’accès.

Microsoft Graph expose des autorisations granulaires qui contrôlent l’accès aux ressources Microsoft Graph, telles que les utilisateurs, les groupes et la messagerie. Deux types d’autorisations sont disponibles pour les scénarios d’accès pris en charge :

  • Autorisations déléguées : également appelées étendues, permettent à l’application d’agir au nom de l’utilisateur connecté.
  • Autorisations d’application : également appelées rôles d’application, permettent à l’application d’accéder aux données par elle-même, sans utilisateur connecté.

En tant que développeur, vous décidez des autorisations Microsoft Graph à demander pour votre application en fonction du scénario d’accès et des opérations que vous souhaitez effectuer. Lorsqu’un utilisateur se connecte à une application, l’application doit spécifier les autorisations qu’elle doit inclure dans le jeton d’accès. Ces autorisations :

  • Peut être préautorisé pour l’application par un administrateur.
  • Peut être accepté directement par l’utilisateur.
  • S’il n’est pas préautorisé, peut nécessiter des privilèges d’administrateur pour accorder le consentement. Par exemple, pour les autorisations avec un plus grand impact potentiel sur la sécurité.

Pour plus d’informations sur les autorisations et le consentement, consultez Présentation des autorisations et du consentement.

Pour plus d’informations sur les autorisations Microsoft Graph et leur utilisation, consultez vue d’ensemble des autorisations Microsoft Graph.

Remarque

Il est préférable de demander les autorisations les moins privilégiés dont votre application a besoin pour accéder aux données et fonctionner correctement. La demande d’autorisations autres que les privilèges nécessaires est une pratique de sécurité médiocre, qui peut empêcher les utilisateurs de donner leur consentement et d’affecter l’utilisation de votre application.

Jetons d’accès

Pour accéder à une ressource protégée, une application doit prouver qu’elle est autorisée à le faire en envoyant un jeton d’accès valide. L’application obtient ce jeton d’accès lorsqu’elle effectue une demande d’authentification à l’Plateforme d'identités Microsoft qui, à son tour, utilise le jeton d’accès pour vérifier que l’application est autorisée à appeler Microsoft Graph.

Les jetons d’accès que le Plateforme d'identités Microsoft émet contiennent des revendications qui sont des détails sur l’application et, dans les scénarios d’accès délégué, l’utilisateur connecté. Les API web telles que Microsoft Graph qui sont sécurisées par le Plateforme d'identités Microsoft utilisent les revendications pour valider l’appelant et s’assurer que l’appelant est autorisé à effectuer l’opération qu’il demande. Pour les scénarios d’accès délégué, les autorisations de l’utilisateur appelant et de l’application font partie des revendications. Pour les scénarios d’application, les autorisations de l’application font partie des revendications. Pour plus d’informations sur les éléments qui constituent des jetons d’accès, consultez Informations de référence sur les revendications de jeton d’accès.

Pour appeler Microsoft Graph, l’application effectue une demande d’autorisation en attachant le jeton d’accès en tant que jeton du porteur à l’en-tête Authorization dans une requête HTTP. Par exemple, l’appel suivant renvoie les informations de profil de l’utilisateur connecté (le jeton d’accès a été raccourci pour une meilleure lisibilité) :

GET https://graph.microsoft.com/v1.0/me/ HTTP/1.1
Host: graph.microsoft.com
Authorization: Bearer EwAoA8l6BAAU ... 7PqHGsykYj7A0XqHCjbKKgWSkcAg==

Pour en savoir plus sur les jetons d’accès Plateforme d'identités Microsoft, consultez Jetons d’ID dans le Plateforme d'identités Microsoft.

Obtenir un jeton d’accès

Nous vous recommandons d’utiliser des bibliothèques d’authentification pour gérer vos interactions avec les Plateforme d'identités Microsoft. Les bibliothèques d’authentification abstractionnt de nombreux détails de protocole, tels que la validation, la gestion des cookies, la mise en cache des jetons et la maintenance de connexions sécurisées, ce qui vous permet de concentrer votre développement sur les fonctionnalités de votre application. Microsoft publie des bibliothèques clientes open source et des intergiciels serveur.

Pour le point de terminaison de la Plateforme d’identités Microsoft :

  • Les bibliothèques clientes MSAL (Microsoft Authentication Library) sont disponibles pour diverses infrastructures, notamment pour .NET, JavaScript, Android et iOS. Toutes les plateformes sont en préversion prise en charge par la production et, si des modifications cassants sont introduites, Microsoft garantit un chemin de mise à niveau.
  • L’intergiciel serveur de Microsoft est disponible pour .NET Core et ASP.NET (OWIN OpenID Connect et OAuth) et pour Node.js (Plateforme d'identités Microsoft Passport.js).
  • Le Plateforme d'identités Microsoft est également compatible avec de nombreuses bibliothèques d’authentification tierces.

Pour obtenir la liste complète des bibliothèques clientes Microsoft, des intergiciels de serveur Microsoft et des bibliothèques tierces compatibles, consultez Plateforme d'identités Microsoft documentation.

Vous pouvez également utiliser les points de terminaison Plateforme d'identités Microsoft directement sans l’aide d’une bibliothèque d’authentification. Si vous souhaitez en savoir plus, consultez les articles suivants :

Contenu connexe