Autorisations déléguées et d’application : choisir le bon modèle pour votre application

By Mirko Peters · 2026-08-11

Bienvenue dans ce nouvel épisode de notre podcast et de notre série consacrée à la maîtrise de Microsoft 365, d’Azure et des outils de développement qui animent l’écosystème cloud moderne. Si vous avez déjà conçu une intégration, écrit un script ou déployé une automatisation d’entreprise avec l’API Microsoft Graph, vous vous êtes forcément heurté au mur des autorisations. Sécuriser votre locataire

Automatically translated with AI from the original post. Read the English original

Bienvenue dans ce nouvel épisode de notre podcast et de notre série consacrée à la maîtrise de Microsoft 365, d’Azure et des outils de développement qui animent l’écosystème cloud moderne. Si vous avez déjà conçu une intégration, écrit un script ou déployé une automatisation d’entreprise avec l’API Microsoft Graph, vous vous êtes forcément heurté au mur des autorisations. Sécuriser votre locataire tout en développant des applications fonctionnelles est l’un des équilibres les plus délicats que vous aurez à trouver, en tant qu’administrateur ou développeur. Le choix entre les différents modèles d’autorisations influe directement sur votre niveau de sécurité, la rapidité de vos déploiements et l’architecture globale de votre système.

Pour approfondir ce sujet complexe, nous avons récemment enregistré un épisode détaillé. Écoutez l’intégralité de la discussion audio sur Microsoft Graph Permissions and Consent Models Explained. Dans cet article de blog qui l’accompagne, nous reprendrons ces notions pour examiner les différences fondamentales entre autorisations déléguées et autorisations d’application, passer en revue les modèles de consentement, présenter les bonnes pratiques et proposer un cadre complet vous permettant de garder vos applications sécurisées et conformes.

Vue d’ensemble des autorisations de l’API Microsoft Graph

Avant d’entrer dans les subtilités des flux d’autorisation spécifiques, il est utile de comprendre ce que sont réellement les autorisations de l’API Microsoft Graph. Dans son principe, Microsoft Graph sert de passerelle unifiée vers les données hébergées dans les services Microsoft 365, notamment Exchange Online, SharePoint, Microsoft Teams, OneDrive et Azure Active Directory (Microsoft Entra ID). Plutôt que d’obliger les développeurs à s’authentifier auprès de plusieurs points de terminaison isolés, Microsoft Graph fournit un point de terminaison REST unique. Cela dit, comme cette API ouvre l’accès à presque tous les recoins du patrimoine numérique d’une organisation, la sécuriser exige un cadre d’autorisations robuste et granulaire.

Autorisations déléguées et autorisations d’application

Lorsque vous enregistrez une application dans la plateforme d’identité Microsoft, vous devez déclarer explicitement la manière dont elle va interagir avec les ressources. Il s’agit, au fond, de choisir entre deux types d’autorisations principaux : les autorisations déléguées et les autorisations d’application. Ce choix détermine la façon dont votre application s’authentifie, au nom de qui ou de quoi elle agit, et les limites des données auxquelles elle peut accéder.

Les autorisations déléguées sont conçues pour les applications côté client ou orientées utilisateur, comme les applications web monopage, les applications mobiles ou les utilitaires de bureau, dont un utilisateur connecté est activement présent. Dans ce modèle, votre application agit *au nom de* l’utilisateur. Elle ne peut accéder qu’aux données et exécuter uniquement les actions que cet utilisateur est lui-même autorisé à effectuer. Lorsqu’un utilisateur lance l’application, il est invité à se connecter et à accorder explicitement son consentement, ce qui délivre un jeton d’accès OAuth 2.0 contenant à la fois l’identité de l’utilisateur et les étendues consenties.

Les autorisations d’application, à l’inverse, sont utilisées par les services en arrière-plan, les démons, les travaux web et les runbooks automatisés qui fonctionnent indépendamment de tout contexte utilisateur. Ici, l’application s’exécute avec sa propre identité. Elle utilise des informations d’identification client, comme un secret client, une paire de clés certificat public/privé ou une identité managée, pour obtenir un jeton d’accès propre à l’application auprès d’Azure AD. Comme aucun utilisateur n’est présent devant un clavier pour s’authentifier, ces autorisations s’étendent à l’ensemble des ressources du locataire. Par conséquent, elles présentent des risques de sécurité nettement plus élevés et exigent toujours le consentement explicite d’un administrateur de locataire.

Différences clés et cas d’usage

Comprendre quand mettre en œuvre chaque modèle d’autorisations permet d’éviter les goulets d’étranglement architecturaux et les failles de sécurité. Voyons un rapide comparatif :

• Autorisations déléguées : l’application travaille pour le compte d’un utilisateur. L’utilisateur doit se connecter et consentir. L’application ne peut voir que ce que l’utilisateur peut voir. Ce modèle convient parfaitement aux applications clientes qui lisent ou écrivent des données personnelles, comme les agendas ou les messages individuels.
• Autorisations d’application : l’application agit en tant que telle. Aucun utilisateur n’a besoin de se connecter. Un administrateur doit donner son consentement. L’application peut consulter et modifier les données de l’ensemble du locataire. Ce modèle convient parfaitement à la synchronisation en arrière-plan, au reporting administratif et aux travaux automatisés de gouvernance.

Le choix du modèle dépend entièrement de l’architecture de votre application. Par exemple, si vous développez un tableau de bord interactif qui affiche le profil d’un utilisateur et sa boîte de réception personnelle, vous devez utiliser des autorisations déléguées. À l’inverse, si vous développez un script automatisé qui analyse chaque nuit, à minuit, toutes les boîtes aux lettres de l’organisation à des fins d’audit de conformité, des autorisations d’application sont nécessaires.

Autorisations déléguées dans Microsoft Graph

Fonctionnement des autorisations déléguées

L’accès délégué est étroitement lié à l’identité de l’utilisateur. Lorsque votre application demande une autorisation déléguée, elle demande en substance au serveur d’autorisation l’autorisation d’agir au nom de l’utilisateur connecté, dans des limites définies. Le jeton d’accès renvoyé par le flux de code d’autorisation OAuth contient des revendications d’étendue (scope) spécifiques qui reflètent à la fois les droits intrinsèques de l’utilisateur et les autorisations demandées par l’application.

• Avec un accès délégué, votre application agit directement en tant qu’utilisateur.
• L’inscription de l’application et l’utilisateur lui-même doivent tous deux disposer des droits sous-jacents appropriés.
• Les étendues (scopes) définissent le plafond exact de ce que votre application peut faire au nom de l’utilisateur.
• Le jeton d’accès obtenu lie ensemble l’identité de l’application et le contexte utilisateur.

Scénarios courants pour les autorisations déléguées

Les autorisations déléguées alimentent la plupart des intégrations de productivité au quotidien. Par exemple, si une application professionnelle de prise de notes doit synchroniser des fichiers vers le OneDrive d’un utilisateur, elle demande l’étendue Files.ReadWrite. Si l’utilisateur n’est pas autorisé à accéder à un document précis, l’API Graph rejettera la requête, même si l’étendue de l’application le permet en théorie. De même, les applications qui utilisent le SDK Microsoft Graph pour envoyer des notifications par e-mail automatisées au nom d’un utilisateur s’appuient sur des étendues déléguées telles que Mail.Send.

Considérations de sécurité et de consentement

Bien que les autorisations déléguées soient intrinsèquement plus sûres que les autorisations d’application à l’échelle du locataire, car elles sont limitées par les droits de l’utilisateur, elles présentent tout de même des défis de sécurité spécifiques. Si une application demande des étendues trop larges, comme un accès complet à la boîte aux lettres et au profil d’annuaire de l’utilisateur, une attaque par hameçonnage réussie ou la compromission de l’application pourrait exposer des données personnelles sensibles. Les développeurs doivent strictement respecter le principe du moindre privilège et ne demander que les étendues nécessaires au fonctionnement immédiat.

Autorisations d’application dans Microsoft Graph

Fonctionnement des autorisations d’application

Les autorisations d’application éliminent totalement l’intervention humaine dans le processus d’authentification. Au lieu d’interagir avec une invite de connexion, l’application s’authentifie directement auprès de Microsoft Entra ID à l’aide d’identifiants client. Le jeton obtenu contient des rôles d’application plutôt que des étendues déléguées, ce qui donne au principal de service un accès étendu et sans restriction à l’ensemble des ressources du locataire.

• Les autorisations d’application fonctionnent entièrement sans utilisateur connecté.
• L’application obtient un jeton uniquement applicatif pour interroger les ressources.
• L’accès est régi par les rôles d’application attribués au principal de service, et non par les privilèges de chaque utilisateur.

Quand utiliser les autorisations d’application

Vous devez réserver strictement les autorisations d’application aux charges de travail back-end, aux démons sans interaction humaine et aux intégrations système à système. Parmi les exemples figurent les moteurs de provisionnement automatique des utilisateurs, les systèmes de sauvegarde centralisés, les outils de réponse aux incidents de sécurité et les scripts de migration de locataire.

Consentement de l’administrateur et implications de sécurité

Comme les autorisations d’application contournent les contraintes propres à chaque utilisateur et accordent un accès à l’échelle du locataire, les utilisateurs standard ne peuvent pas les consentir. Seul un administrateur disposant de privilèges peut accorder le consentement pour une application. Une configuration erronée des autorisations d’application, par exemple l’octroi de Directory.ReadWrite.All ou Mail.ReadWrite.All à une application d’arrière-plan non fiable ou mal conçue, peut exposer l’ensemble du locataire Microsoft 365 à une compromission totale. Auditez régulièrement les principaux de service de vos applications d’entreprise.

Avantages et inconvénients des autorisations de l’API Microsoft Graph

Avantages

• Modèle d’autorisation unifié : un cadre d’autorisation unique et cohérent pour l’ensemble des services Microsoft 365 simplifie l’administration.
• Étendues granulaires : des étendues déléguées et d’application précises permettent de mettre en place des architectures respectant le principe du moindre privilège.
• OAuth2/OpenID Connect standard : s’appuie sur des protocoles de sécurité reconnus par l’industrie pour une intégration d’identité simple.
• Intégration RBAC : s’intègre en toute transparence aux rôles Azure AD et aux stratégies d’accès conditionnel pour une conformité centralisée.
• Consentement progressif : permet aux applications de demander des autorisations supplémentaires au fil du temps, plutôt que d’exiger l’ensemble dès le départ.

Inconvénients

• Complexité : la combinaison des étendues déléguées, des rôles d’application et des modèles de consentement administrateur peut dérouter les novices.
• Risques liés aux privilèges élevés : une mauvaise configuration d’autorisations étendues (comme Sites.FullControl.All) peut exposer une quantité considérable de données de l’entreprise.
• Goulots d’étranglement liés au consentement administrateur : exiger une approbation administrative pour des autorisations à fort impact peut ralentir les cycles de développement agiles.
• Documentation fragmentée : les développeurs doivent souvent croiser plusieurs dépôts de documentation Microsoft pour établir le comportement exact des API.

Modèles de consentement et bonnes pratiques

Consentement utilisateur ou administrateur dans Microsoft Graph

Gérer la manière dont le consentement est obtenu est essentiel pour la gouvernance de l’organisation. Le consentement utilisateur permet à chaque personne d’autoriser des applications à accéder à ses données personnelles. Le consentement administrateur déplace le point de validation vers les administrateurs informatiques, qui évaluent les demandes des applications au nom de l’ensemble de l’organisation. Les référentiels de sécurité modernes des entreprises désactivent fréquemment le consentement utilisateur, ce qui impose que toute intégration d’application passe par des workflows formalisés de pré-approbation administrative.

Impact des stratégies du locataire sur les autorisations

Les stratégies de locataire d’entreprise peuvent modifier en profondeur le comportement de votre application à l’exécution. Si un administrateur a imposé des stratégies d’accès conditionnel strictes, par exemple l’exigence d’une authentification multifacteur (MFA) ou d’appareils joints à Azure AD hybride et conformes, une application qui tente d’obtenir un jeton Graph sans remplir ces critères sera bloquée. Les développeurs doivent concevoir leurs applications pour gérer avec élégance les échecs d’acquisition de jetons et fournir des étapes de remédiation claires.

Stratégies pour un flux de consentement fluide

Pour éviter les frictions pour les utilisateurs et les blocages administratifs, planifiez votre stratégie d’autorisations avant d’écrire le moindre code. Mettez en œuvre des schémas de consentement progressif : votre application demande les étendues d’identité de base dès le départ, et ne sollicite les autorisations de ressources spécialisées que lorsque l’utilisateur accède à ces fonctionnalités précises. Utilisez des workflows de pré-approbation automatisés dans Microsoft Entra ID pour accélérer le développement tout en conservant un contrôle de sécurité strict.

Erreurs courantes concernant les autorisations de l’API Microsoft Graph

• Confondre les autorisations déléguées et les autorisations d’application, et méconnaître les exigences de contexte utilisateur.
• Demander des autorisations excessives dès le départ au lieu d’adopter une approche du moindre privilège.
• Ne pas tenir compte des exigences de consentement administrateur lors du déploiement de services en arrière-plan.
• Supposer que les modifications d’autorisations dans le portail Azure prennent effet immédiatement, sans actualisation du jeton.
• Présenter un jeton d’accès délégué là où un jeton d’informations d’identification client est requis.
• Ignorer les stratégies d’accès conditionnel qui bloquent les requêtes de l’API Graph à l’exécution.
• Négliger de valider les revendications d’étendues dans le code de l’application à l’exécution.
• Ne pas auditer régulièrement les autorisations d’application accordées et les principaux de service.

Liste de contrôle des autorisations de l’API Microsoft Graph

Utilisez cette liste de contrôle opérationnelle pour guider votre équipe dans la conception, la mise en œuvre et l’audit des autorisations de l’API Microsoft Graph de manière sécurisée :

Conclusion

Naviguer parmi les autorisations de l’API Microsoft Graph ne doit pas être un exercice frustrant. En comprenant clairement les différences opérationnelles entre les autorisations déléguées (qui exigent un utilisateur connecté et s’exécutent dans les limites de cet utilisateur) et les autorisations d’application (qui s’exécutent sans contrainte en arrière-plan et exigent un consentement administrateur), vous pouvez concevoir des solutions sécurisées et évolutives. Adopter le principe du moindre privilège, imposer un audit rigoureux et exploiter les outils de gouvernance de l’entreprise permettront de protéger votre environnement Microsoft 365 sans freiner l’innovation.

Pour des conseils d’experts supplémentaires, des stratégies concrètes et des analyses approfondies de la sécurisation de votre environnement cloud, écoutez notre synthèse audio complète de l’épisode associé : Microsoft Graph Permissions and Consent Models Explained. Gardez vos autorisations rigoureuses, vos identifiants sécurisés et bon développement !