Commentaires Modifier

Microsoft Graph : principes de base de l’authentification et de l’autorisation

  • Article
  • 9 minutes de lecture

Pour appeler Microsoft Graph, votre application doit se procurer un jeton d’accès auprès de la plateforme d’identités Microsoft. Le jeton d’accès contient des informations sur votre application et les autorisations dont elle dispose pour accéder aux ressources et aux API disponibles via Microsoft Graph. Pour obtenir un jeton d’accès, votre application doit être inscrite sur la plateforme d’identités Microsoft et être autorisée par un utilisateur ou un administrateur à accéder aux ressources Microsoft Graph dont elle a besoin.

Cet article fournit une vue d’ensemble de la plateforme d’identités Microsoft, des jetons d’accès et de la façon dont votre application peut obtenir des jetons d’accès. Pour plus d’informations sur la plateforme d’identités Microsoft, consultez Qu’est-ce que la plateforme d’identités Microsoft ?. Si vous savez comment intégrer une application à la Plateforme d’identités Microsoft pour développeurs pour obtenir des jetons, consultez les informations et les exemples spécifiques à Microsoft Graph dans la section Étapes suivantes .

Inscrire votre application sur la Plateforme d’identités Microsoft

Pour pouvoir se procurer un jeton auprès de la Plateforme d’identités Microsoft, votre application doit d’abord être inscrite sur le portail Azure. L’inscription intègre votre application à la Plateforme d’identités Microsoft et établit les informations qu’elle utilise pour obtenir des jetons, notamment :

  • ID de l’application : identifiant unique attribué par la Plateforme d’identités Microsoft.
  • URI/URL de redirection : un ou plusieurs points de terminaison sur lesquels votre application recevra les réponses de la Plateforme d’identités Microsoft. (Pour les applications natives et mobiles, il s’agit l’URI est attribué par la Plateforme d’identités Microsoft.)
  • Clé secrète client : mot de passe ou paire clé publique/clé privée que votre application utilise pour l’authentification auprès de la Plateforme d’identités Microsoft pour développeurs. (Non nécessaire pour les applications natives ou mobiles).

Les propriétés configurées lors de l’inscription sont utilisées dans la demande. Par exemple, dans la demande de jeton suivante : client_id est l’ID de l’application, redirect_uri est l’un des URI de redirection enregistrés par votre application et client_secret est la clé secrète client.

// Line breaks for legibility only

POST /common/oauth2/v2.0/token HTTP/1.1
Host: https://login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&scope=user.read%20mail.read
&code=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq3n8b2JRLk4OxVXr...
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&grant_type=authorization_code
&client_secret=JqQX2PNo9bpM0uEihUPzyrh    // NOTE: Only required for web apps

Autorisations de Microsoft Graph

Microsoft Graph présente des autorisations précises qui contrôlent l’accès des applications aux ressources, comme les utilisateurs, les groupes et les courriers. En tant que développeur, vous décidez des autorisations Microsoft Graph à demander pour votre application. Lorsqu’un utilisateur se connecte à votre application, celui-ci (ou un administrateur, selon le cas) a la possibilité de consentir à ces autorisations. Si l’utilisateur y consent, votre application a accès aux ressources et aux API qu’elle a demandées. Pour les applications auxquelles les utilisateurs n’ont pas à se connecter, les autorisations peuvent être préalablement consenties par un administrateur lorsque l’application est installée.

Meilleures pratiques de demande d’autorisations

Notes

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.

Autorisation déléguée et autorisation d’application

Microsoft Graph comprend deux types d’autorisations.

  • Les autorisations déléguées sont utilisées par les applications qui ont un utilisateur connecté. Pour ces applications, l’utilisateur ou un administrateur consent aux autorisations demandées par l’application, et l’application peut agir en tant qu’utilisateur connecté lors des appels à Microsoft Graph. Certaines autorisations déléguées peuvent être consenties par des utilisateurs non administrateurs, mais certaines autorisations avec des privilèges plus élevés nécessitent le consentement de l’administrateur.

  • Les autorisations de l’application sont utilisées par les applications qui s’exécutent sans utilisateur connecté. Par exemple, les applications qui s’exécutent en tant que démons ou services d’arrière-plan. Les autorisations de l’application peuvent uniquement être consenties par un administrateur.

Les autorisations effectives sont les autorisations que votre application aura lorsqu’elle effectue des requêtes à Microsoft Graph. Les autorisations effectives sont déterminées par une combinaison des autorisations Microsoft Graph que vous avez accordées à l’application, ainsi que des privilèges et de l’utilisateur ou de l’application appelante. Au sein des organisations, la stratégie ou l’appartenance à un ou plusieurs rôles déterminent les privilèges de l’utilisateur connecté ou d’une application. Il est important de comprendre la différence entre une autorisation déléguée et une autorisation de l’application dont bénéficie votre application, ainsi que ses autorisations effectives lorsqu’elle appelle Microsoft Graph.

Autorisations effectives dans les scénarios d’autorisation déléguée ou d’autorisation de l’application uniquement

  • Pour les autorisations déléguées, les autorisations effectives de votre application correspondent à l’intersection la moins privilégiée des autorisations déléguées accordées à l’application (par consentement) et des privilèges de l’utilisateur actuellement connecté. Votre application ne peut jamais avoir plus de privilèges que l’utilisateur connecté.

    Supposons que votre application dispose de l’autorisation déléguée User.ReadWrite.All et appelle l’API Update user. Cette autorisation accorde nominalement à votre application l’autorisation de lire et de mettre à jour le profil de chacun des utilisateurs d’une organisation. Toutefois, en raison des autorisations effectives, les restrictions suivantes s’appliquent aux privilèges de l’utilisateur connecté :

    • Si l’utilisateur connecté est un administrateur global, votre application peut mettre à jour le profil de chaque utilisateur de l’organisation.
    • Si l’utilisateur connecté n’a pas un rôle d’administrateur, votre application peut mettre à jour uniquement le profil de l’utilisateur connecté. Il ne met pas à jour les profils des autres utilisateurs de l’organisation, car l’utilisateur connecté ne dispose pas de ces privilèges.

  • Pour les autorisations d’application, les autorisations effectives de votre application correspondent au niveau de privilèges total impliqué par l’autorisation. Par exemple, une application qui possède l’autorisation d’application User.ReadWrite.All peut mettre à jour le profil de chaque utilisateur de l’organisation.

Comparaison de l’autorisation déléguée et de l’autorisation d’application
Autorisations déléguées Autorisations de l’application
Scénarios de type d’application Application Web/ Mobile/ mono-page (SPA) Web / Daemon
Contexte d’accès Obtenir l’accès au nom d’un utilisateur Obtenir l’accès en tant que service
Qui peut consentir
  • Les utilisateurs peuvent donner leur consentement à leurs données
  • Les administrateurs peuvent donner leur consentement à tous les utilisateurs
    		•  Seul l’administrateur peut donner son consentement
    Autres noms
  • scopes
  • Autorisations OAuth2
    		•
  • Rôles d’application
  • Autorisations d’application uniquement
  • Autorisations d’accès direct
    		•
    Résultat du consentement oauth2PermissionGrants appRoleAssignments

    Microsoft Graph expose les autorisations déléguées et d’application, mais autorise les demandes en fonction des autorisations effectives de l’application.

    Pour obtenir la liste complète des autorisations déléguées et des autorisations d’application de Microsoft Graph, ainsi que des autorisations nécessitant le consentement de l’administrateur, consultez la rubrique Référence des autorisations.

    Jetons d’accès

    Les jetons d’accès qui sont émis par la Plateforme d’identités Microsoft contiennent des informations (revendications) que les API web sécurisées par la Plateforme d’identités Microsoft, comme Microsoft Graph, utilisent pour valider l’appelant et s’assurer que celui-ci dispose des autorisations nécessaires pour effectuer l’opération demandée. L’appelant doit traiter les jetons d’accès comme des chaînes opaques, car le contenu du jeton est destiné à l’API uniquement. Lorsque vous appelez Microsoft Graph, protégez toujours les jetons d’accès en les transmettant sur un canal sécurisé qui utilise le protocole TLS (Transport Layer Security).

    L’exemple suivant montre un jeton d’accès à la Plateforme d’identités Microsoft pour développeur :

    EwAoA8l6BAAU7p9QDpi/D7xJLwsTgCg3TskyTaQAAXu71AU9f4aS4rOK5xoO/SU5HZKSXtCsDe0Pj7uSc5Ug008qTI+a9M1tBeKoTs7tHzhJNSKgk7pm5e8d3oGWXX5shyOG3cKSqgfwuNDnmmPDNDivwmi9kmKqWIC9OQRf8InpYXH7NdUYNwN+jljffvNTewdZz42VPrvqoMH7hSxiG7A1h8leOv4F3Ek/XbrnbEErTDLWrV6Lc3JHQMs0bYUyTBg5dThwCiuZ1evaT6BlMMLuSCVxdBGzXTBcvGwihFzZbyNoX+52DS5x+RbIEvd6KWOpQ6Ni+1GAawHDdNUiQTQFXRxLSHfc9fh7hE4qcD7PqHGsykYj7A0XqHCjbKKgWSkcAg==

    Pour appeler Microsoft Graph, vous devez joindre le jeton d’accès sous la forme d’un jeton du porteur à l’en-tête d’autorisation 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é tronqué pour une meilleure lisibilité) :

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

    Les jetons d’accès sont un type de jetons de sécurité fournis par la plateforme d’identités Microsoft. Ils ont une courte durée de vie mais une durée de vie par défaut variable. Pour plus d’informations sur les jetons d’accès et la façon dont les clients utilisent les jetons d’accès, consultez Jetons d’accès.

    Obtenir un jeton d’accès

    Comme la plupart des développeurs, vous utiliserez probablement des bibliothèques d’authentification pour gérer vos interactions de jetons avec la Plateforme d’identités Microsoft. Les bibliothèques d’authentification extraient du développeur de nombreuses informations relatives au protocole, telles que la validation, la gestion des cookies, la mise en cache des jetons et le maintien de connexions sécurisées, et vous permettent de concentrer votre développement sur les fonctionnalités de votre application. Microsoft publie des bibliothèques clientes et des intergiciels de serveur à code source ouvert.

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

    • Les bibliothèques clientes MSAL sont disponibles pour .NET, JavaScript, Android et Objective-C. Toutes les plates-formes sont présentées en mode d’aperçu pris en charge par la production et, dans le cas de modifications de dernière minute, Microsoft garantit un chemin d’accès pour la mise à niveau.
    • Les intergiciels serveur de Microsoft sont disponibles pour .NET Core et ASP.NET (OWIN OpenID Connect et OAuth), ainsi que pour Node.js (Plateforme d’identités Microsoft, Passport.js).
    • La Plateforme d’identités Microsoft est compatible avec de nombreuses bibliothèques d’authentification tierces.

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

    Vous n’avez pas besoin d’utiliser une bibliothèque d’authentification pour obtenir un jeton d’accès. Pour en savoir plus sur l’utilisation directe des points de terminaison de la Plateforme d’identités Microsoft sans l’aide d’une bibliothèque d’authentification, consultez l’article Authentification sur la Plateforme d’identités Microsoft.

    Étapes suivantes

    Si vous êtes prêt à vous immerger dans le code, vous pouvez utiliser les ressources suivantes pour vous aider à implémenter l’authentification et l’autorisation avec la Plateforme d’identités Microsoft dans votre application.

    Exemples et formation Microsoft Graph

    Pour vous permettre de démarrer facilement, nous avons créé une série de modules de formation et d’autres ressources qui expliquent comment s’authentifier et utiliser l’API sur différentes plateformes.

    Exemples et documentation relatifs à la Plateforme d’identités Microsoft

    La documentation relative à la Plateforme d’identités Microsoft contient des articles et des exemples qui se concentrent spécifiquement sur l’authentification et l’autorisation avec la Plateforme d’identités Microsoft.

    Voir aussi