Appliquer les meilleures pratiques à Microsoft Graph

  • 3 minutes

Cette leçon décrit les meilleures pratiques à appliquer pour tirer le meilleur parti de Microsoft Graph et rendre votre application plus fiable pour les utilisateurs finaux.

Authentification

Pour accéder aux données dans Microsoft Graph, votre application doit acquérir un jeton d’accès OAuth 2.0 et le présenter à Microsoft Graph par l’une des méthodes suivantes :

  • L’en-tête de demande HTTP Authorization, en tant que jeton du Porteur
  • Le constructeur du client Graph, lors de l’utilisation d’une bibliothèque de client Microsoft Graph

Utilisez l’API de la bibliothèque d’authentification Microsoft, MSAL pour obtenir le jeton d’accès à Microsoft Graph.

Appliquez les meilleures pratiques suivantes pour le consentement et l’autorisation dans votre application :

  • Utilisez le privilège minimum. Demandez uniquement les autorisations qui sont nécessaires et uniquement quand vous en avez besoin. Pour les API que votre application appelle, consultez la section Autorisations dans les rubriques de la méthode. Par exemple, consultez Création d’un utilisateur et choisissez les autorisations les plus faibles.

  • Utilisez le type d’autorisation correct en fonction des scénarios. Si vous créez une application interactive où un utilisateur connecté est présent, votre application doit utiliser des autorisations déléguées. Toutefois, si votre application s’exécute sans utilisateur connecté, comme un service ou démon en arrière-plan, votre application doit utiliser des autorisations d’application.

    Attention

    L’utilisation d’autorisations d’application pour les scénarios interactifs peut compromettre la conformité et la sécurité de votre application. Veillez à vérifier les privilèges de l’utilisateur pour vous assurer qu’il ne dispose pas d’un accès indésirable aux informations ou qu’il ne contourne pas les stratégies configurées par un administrateur.

  • Envisagez l’expérience de l’utilisateur final et de l’administrateur. Affecte directement les expériences de l’utilisateur final et de l’administrateur. Par exemple :

  • Envisagez les applications multilocataires. Attendez-vous à ce que les clients disposent de plusieurs contrôles d’application et de consentement dans différents États. Par exemple :

    • Les administrateurs clients peuvent désactiver la capacité des utilisateurs finaux à donner leur consentement aux applications. Dans ce cas, un administrateur doit donner son consentement pour le compte de ses utilisateurs.

    • Les administrateurs clients peuvent définir des stratégies d’autorisation personnalisées, comme empêcher les utilisateurs de lire des profils d’autres utilisateurs, ou limiter la création de groupes en libre-service à un ensemble limité d’utilisateurs. Dans ce cas, votre application doit s’attendre à gérer la réponse d’erreur 403 lorsqu’elle agit pour le compte d’un utilisateur.

Gérer efficacement les réponses

Selon les requêtes que vous effectuez pour Microsoft Graph, vos applications doivent être prêtes à gérer différents types de réponses. Voici quelques-unes des pratiques les plus importantes à suivre pour vous assurer que votre application se comporte de manière fiable et prévisible pour vos utilisateurs finaux. Par exemple :

  • Pagination : Lorsque vous interrogez une collection de ressources, Microsoft Graph peut retourner le résultat sur plusieurs pages, en raison des limites de taille de page côté serveur. Votre application doit toujours gérer la possibilité que les réponses soient paginées par nature, mais également utiliser la propriété @odata.nextLink pour obtenir l’ensemble de résultats paginé suivant, jusqu’à la lecture des pages du jeu de résultats. La page finale n’inclut pas de propriété @odata.nextLink. Pour plus d’informations, consultez Pagination.

  • Énumérations évolutives : L’ajout de membres à des énumérations existantes peut casser des applications qui utilisent déjà ces énumérations. Les énumérations évolutives sont un mécanisme utilisé par l’API Microsoft Graph pour ajouter de nouveaux membres à des énumérations existantes sans entraîner de modification avec rupture pour les applications. Par défaut, une opération GET retourne uniquement les membres connus pour les propriétés des types enum évolutifs et votre application doit gérer uniquement les membres connus. Si vous concevez votre application pour qu’elle gère également les membres inconnus, vous pouvez choisir de recevoir ces membres à l’aide d’un en-tête de demande HTTP Prefer.

Stockage local des données

Votre application devrait idéalement faire des appels à Microsoft Graph pour récupérer des données en temps réel si nécessaire. Vous devez uniquement mettre en cache ou stocker localement les données nécessaires à un scénario spécifique. Si ce cas d’utilisation est couvert par vos conditions d’utilisation et votre politique de confidentialité, et qu’il n’enfreint pas les Conditions d’utilisation des API Microsoft, votre application doit également implémenter des stratégies de rétention et de suppression appropriées.