Démystifier OAuth 2.0 dans Microsoft Graph : autorisations déléguées et autorisations d’application

Par Mirko Peters · 2026-08-11 · Mis à jour 2026-08-28

Bon retour sur le blog ! Si vous avez exploré en profondeur l'automatisation de Microsoft 365, vous vous êtes probablement heurté aux limites que dressent les connecteurs natifs et les approches traditionnelles …

Traduit automatiquement par IA à partir de l'article original. Lire l'original en anglais

Bienvenue sur le blog ! Si vous avez poussé loin l’automatisation de Microsoft 365, vous vous êtes probablement heurté aux limites imposées par les connecteurs natifs et les scripts traditionnels. Naviguer dans la complexité de l’authentification peut vite devenir délicat lorsqu’il s’agit d’automatiser Microsoft 365, en particulier pour concilier une sécurité robuste et une expérience fluide. Que vous développiez des applications d’entreprise personnalisées ou que vous mettiez en place des traitements automatisés en arrière-plan, bien maîtriser les modèles d’authentification est essentiel. Cet article décortique les jetons, les étendues et les flux de consentement afin de vous aider à choisir le bon modèle, qu’il s’agisse de traitements centrés sur l’utilisateur ou de tâches de fond sans intervention humaine. Entrons immédiatement dans le vif du sujet et démystifions le fonctionnement d’OAuth 2.0 au service de l’API Microsoft Graph.

Introduction à l’authentification Microsoft Graph

Microsoft Graph est la passerelle unifiée donnant accès à l’ensemble de l’écosystème Microsoft 365. Plutôt que de dialoguer avec des API distinctes et fragmentées pour Exchange, SharePoint, Teams et Azure Active Directory (désormais Microsoft Entra ID), les développeurs et les administrateurs informatiques peuvent accéder à tous ces services via un point de terminaison unique. Toutefois, comme Graph contrôle l’accès à des données d’entreprise sensibles, sécuriser cette passerelle exige un cadre d’authentification rigoureux. Comprendre comment l’identité, les jetons d’accès et les autorisations s’articulent constitue la première étape vers la création d’automatisations fiables et sécurisées, qui ne cèdent pas sous la pression et ne déclenchent pas d’alertes de sécurité.

Comprendre OAuth 2.0 dans le contexte de Microsoft 365

Au cœur de son fonctionnement, Microsoft Graph s’appuie sur le protocole OAuth 2.0 pour l’autorisation. Lorsque votre application ou votre script souhaite dialoguer avec Graph, il ne peut pas simplement transmettre ses identifiants en clair sur le réseau. Il doit au contraire demander un jeton d’accès auprès de la plateforme d’identité Microsoft (Entra ID). Ce jeton d’accès joue le rôle d’un passeport numérique sécurisé : il indique à Microsoft Graph qui effectue la requête, quelle application est utilisée et, surtout, quelles autorisations précises (étendues) ont été accordées à ce jeton. Sans jeton valide, Graph rejette immédiatement la requête avec une erreur standard d’accès non autorisé.

Autorisations déléguées : quand agir au nom de l’utilisateur

Le choix du bon modèle d’autorisation dépend entièrement de la nature de votre charge de travail. Les autorisations déléguées sont conçues pour les applications qui s’exécutent avec l’appui d’un utilisateur connecté. Lorsqu’une application utilise des autorisations déléguées, elle agit au nom de l’utilisateur actuellement connecté. Si un utilisateur exécute un script pour lire son propre calendrier ou mettre à jour sa photo de profil, Graph évalue la requête non seulement en fonction de ce que l’application est autorisée à faire, mais aussi en fonction de ce à quoi l’utilisateur lui-même a accès. Si l’utilisateur n’est pas autorisé à consulter une boîte aux lettres donnée, le jeton délégué ne l’y autorisera pas davantage. Ce modèle convient parfaitement aux applications destinées aux utilisateurs, aux outils interactifs et aux scripts de productivité personnelle.

Autorisations d’application : alimenter les traitements de fond sans intervention humaine

À l’inverse, que faire lorsqu’un script ou un service doit s’exécuter à minuit sans qu’aucun utilisateur ne soit devant son clavier ? Pour les traitements de fond sans intervention humaine, les services de type démon et les outils de reporting à l’échelle du locataire, vous avez besoin d’autorisations d’application. Dans ce modèle, l’application fonctionne indépendamment de tout contexte utilisateur : elle s’exécute sous sa propre identité. Comme aucun utilisateur ne peut se connecter et accorder son consentement de manière interactive, les autorisations d’application exigent une pré-autorisation explicite d’un administrateur du locataire. Une fois accordées, elles permettent à l’application d’accéder aux données de l’ensemble de l’organisation. Ce modèle est donc particulièrement puissant pour l’automatisation administrative, les scripts d’intégration et la surveillance de la conformité, mais il exige aussi une supervision de sécurité rigoureuse.

Étendues, jetons et flux de consentement

Le vocabulaire de l'authentification et de l'autorisation peut sembler complexe, mais décomposer le flux de travail en clarifie le fonctionnement. Les étendues d'autorisation (scopes) sont les autorisations précises que votre application demande, comme User.Read.All ou Mail.Read. Lorsqu'un utilisateur ou un administrateur autorise une application, il examine et approuve ces étendues. Une fois approuvées, la plateforme d'identité émet un jeton JSON Web (JWT). Votre code inclut ce jeton dans l'en-tête HTTP Authorization de chaque requête envoyée à Microsoft Graph. Bien gérer le consentement permet à votre application d'obtenir ces jetons sans difficulté et sans se heurter à des obstacles imprévus.

Éviter le purgatoire du consentement administrateur

L'un des points de friction les plus fréquents, pour les développeurs comme pour les administrateurs, est l'attente d'une approbation administrative. Lorsqu'une application demande des étendues d'application à privilèges élevés ou des étendues déléguées sensibles, Microsoft Entra ID peut exiger qu'un administrateur consente à l'application avant l'émission de tout jeton. Si votre pipeline de déploiement suppose que les utilisateurs peuvent donner leur propre consentement et qu'ils se retrouvent soudain bloqués par les stratégies du locataire, votre automatisation s'arrête complètement. Pour éviter ce purgatoire du consentement administrateur, établissez toujours à l'avance la liste de vos autorisations requises, documentez la justification métier et coordonnez-vous avec vos administrateurs globaux ou d'application pour préconfigurer, si nécessaire, le consentement à l'échelle du locataire.

Pièges courants et solutions

Même les développeurs expérimentés rencontrent parfois des obstacles d'autorisation frustrants lorsqu'ils travaillent avec Microsoft Graph. Voyons quelques problèmes courants et comment les résoudre :

• Ça marche chez moi, ça échoue chez les autres : généralement causé par un consentement manquant ou des étendues incorrectes. Solution : documentez clairement les étendues requises et configurez le consentement administrateur à l'échelle du locataire lorsque cela est approprié.
• Surextraction de charges volumineuses : récupérer la totalité des listes d'utilisateurs sans filtrage entraîne des délais d'expiration et de la limitation de débit. Solution : utilisez $select, $top, la pagination et les requêtes delta.
• Boucles infinies d'erreurs 401/403 : causées par un jeton expiré ou par l'utilisation d'une autorisation déléguée pour une tâche sans utilisateur. Solution : mettez en place un mécanisme robuste de renouvellement des jetons et passez aux autorisations d'application pour les tâches en arrière-plan.
• Atteinte des limites de débit : recevoir des réponses 429 signifie que vous envoyez les requêtes trop rapidement. Solution : implémentez un backoff exponentiel, respectez l'en-tête Retry-After et regroupez les opérations par lots.
• Prolifération des secrets : coder en dur des secrets client dans les scripts constitue un risque de sécurité majeur. Solution : utilisez Azure Key Vault, les identités managées ou des variables d'environnement sécurisées.

Bonnes pratiques de sécurité et de gouvernance

Lorsque vous ouvrez l'accès à votre locataire Microsoft 365 via une API, la sécurité doit être votre priorité absolue. Appliquer le principe du moindre privilège signifie ne demander que le strict minimum d'étendues nécessaires au fonctionnement de votre application. Ne demandez jamais Directory.AccessAsUser.All simplement pour lire le nom d'affichage d'un utilisateur. Tenez un registre clair du consentement détaillant les applications qui ont accès à votre locataire, isolez totalement vos inscriptions d'applications de développement, de test et de production, et définissez un calendrier strict de rotation des secrets clients et des certificats.

Vos premières requêtes réelles (exemples)

Une fois votre modèle d'authentification en place, vous pouvez commencer à exécuter des requêtes sur l'API Graph. Voici quelques exemples pratiques que vous pouvez adapter :

• Nouveaux collaborateurs depuis une date :
  GET /users?$filter=createdDateTime ge 2025-10-01T00:00:00Z&$select=id,displayName,mail,department
• Mes prochaines réunions :
  GET /me/events?$top=10&$select=subject,start,end,organizer,webLink
• Membres d'un groupe :
  GET /groups/{group-id}/members?$select=id,displayName,mail
• Utilisateurs modifiés (delta) :
  GET /users/delta?$select=id,displayName,mail

Outils recommandés

Utiliser les bons outils facilite considérablement la création et le débogage des requêtes Microsoft Graph. Graph Explorer est un terrain de jeu web incontournable pour tester les points de terminaison et vérifier les indications de consentement. Pour l'écriture de code, les SDK Microsoft Graph (.NET, JavaScript, Python) masquent une grande partie de la plomberie HTTP sous-jacente. Les extensions Postman ou REST Client de votre IDE sont excellentes pour gérer les collections et les environnements, tandis que Power Automate, Logic Apps et PowerShell assurent brillamment l'automatisation des flux visuels et opérationnels.

Questions fréquentes

Autorisations déléguées ou d'application : comment choisir ?

Les tâches centrées sur l’utilisateur correspondent le mieux aux autorisations déléguées. Les tâches non supervisées, les processus d’arrière-plan (daemons) et les tâches d’administration étendues nécessitent des autorisations d’application, accompagnées d’un consentement administrateur approprié.

Comment éviter la limitation de débit ?

Utilisez $select pour limiter la taille des charges utiles, implémentez la pagination et les requêtes delta, regroupez les requêtes lorsque c’est possible, et concevez toujours vos scripts pour gérer proprement les codes d’état 429 avec une logique de nouvelle tentative.

Peut-on utiliser Graph sans écrire de code ?

Oui ! Vous pouvez prototyper des points de terminaison dans Graph Explorer et orchestrer des flux de travail avec Power Automate. Pour une logique complexe, passez aux SDK officiels ou aux scripts PowerShell.

Microsoft Graph est-il suffisamment sécurisé pour les rapports de conformité ?

Absolument. Mis en œuvre selon le principe du moindre privilège, avec une journalisation centralisée, des flux de consentement audités et une gestion sécurisée des secrets, Microsoft Graph répond aux exigences strictes de conformité des entreprises.

Conclusion

Maîtriser l’authentification dans Microsoft Graph est la clé ultime pour tout administrateur, architecte ou développeur souhaitant exploiter pleinement la puissance de Microsoft 365. En comprenant la distinction essentielle entre autorisations déléguées et autorisations d’application, en gérant rigoureusement vos étendues (scopes) et vos jetons, et en appliquant une gouvernance de sécurité stricte, vous pouvez créer des automatisations à la fois puissantes et sécurisées. Pour aller encore plus loin sur ce sujet, explorer les exemples de code et découvrir des stratégies avancées de gestion des erreurs et de limitation de débit, n’hésitez pas à consulter l’épisode de podcast associé : Automate Microsoft 365 with Microsoft Graph API. Bonne automatisation !