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

By Mirko Peters · 2026-04-26 · Updated 2026-07-18

Comparez les autorisations déléguées et les autorisations d’application dans Microsoft Entra ID, et choisissez le modèle d’accès adapté aux API sécurisées, à l’automatisation et au développement d’applications.

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

Lorsque vous travaillez avec Microsoft Entra ID, déterminer qui peut faire quoi, et dans quelles circonstances, est bien plus qu’un détail technique. C’est le socle du développement d’applications sécurisées, de l’automatisation et de la gestion globale des identités dans le cloud de Microsoft. Il existe un monde de différence entre permettre à un utilisateur d’accorder à votre application juste assez d’accès pour agir en son nom (autorisations déléguées) et donner à une application les clés pour agir de manière indépendante (autorisations d’application).

Une erreur de configuration peut ouvrir la porte à une exposition non désirée de données, à des problèmes de conformité, voire à des incidents de sécurité. En revanche, bien les configurer vous permet d’automatiser plus facilement, de gouverner plus clairement et de satisfaire vos auditeurs. Ce guide vous présente l’essentiel : les rouages de ces types d’autorisations, leur fonctionnement concret, ainsi que tous les aspects liés à la sécurité, à la gouvernance et à l’exploitation dont vous avez besoin pour faire le meilleur choix pour votre environnement. Replaçons les autorisations à leur juste place, car un accès étendu implique une responsabilité certaine.

Contexte et introduction aux modèles d’autorisations dans Microsoft Identity

Les autorisations dans Microsoft Entra ID ne sont pas de simples cases à cocher ; elles constituent un cadre fondamental intégré à la manière dont applications et utilisateurs interagissent dans Microsoft 365, Azure et au-delà. Lorsque Microsoft a migré l’identité vers le cloud, il a fallu trouver un moyen pour que les services et les outils tiers puissent interagir en toute sécurité, sans accorder à tout le monde un accès général et illimité. Ainsi sont apparues les autorisations déléguées et les autorisations d’application.

Ces modèles permettent de gérer avec précision qui peut accéder à quoi, en établissant des limites claires entre ce qu’un utilisateur peut approuver et ce qu’un seul administrateur doit autoriser. Ils sont le fruit de plusieurs années d’apprentissage, parfois douloureux, à partir des comptes de service Active Directory classiques et d’un accès tout ou rien peu pratique. Comprendre ces modèles n’est pas seulement une bonne pratique : c’est essentiel pour respecter les exigences de conformité, appliquer le modèle Zero Trust et éviter que les opérations quotidiennes ne s’arrêtent brutalement à cause de mauvaises configurations de sécurité.

Autorisations d’application et autorisations déléguées : concepts clés et scénarios concrets

Résumons simplement la différence entre autorisations déléguées et autorisations d’application. Considérez les autorisations déléguées comme une application qui agit en tant qu’assistant : elle n’obtient un accès que pendant qu’un utilisateur précis est connecté, et elle est limitée à ce que cet utilisateur est lui-même autorisé à faire. Les autorisations d’application, en revanche, permettent à votre application d’agir de façon autonome, comme un responsable sans supervision disposant de ses propres clés. Elle n’a pas besoin qu’un utilisateur soit présent.

Avec les autorisations déléguées, l’authentification implique toujours un utilisateur. Ainsi, lorsqu’une personne se connecte à une application qui doit accéder à ses e-mails ou à son agenda, elle accorde à l’application une fenêtre temporaire pour agir avec ses propres droits. Si l’utilisateur se déconnecte, cette fenêtre se referme. C’est idéal pour les applications qui travaillent à la demande de l’utilisateur, comme les interfaces web, les bots Teams ou les applications mobiles de productivité.

Avec les autorisations d’application, l’application s’authentifie elle-même avec sa propre identité (un principal de service) et obtient son propre jeton. C’est ce qui alimente l’automatisation et les tâches en arrière-plan, comme une intégration système qui synchronise les données entre SharePoint et votre CRM pendant la nuit. Aucune interaction utilisateur n’est requise : l’application exécute ses tâches selon son propre calendrier et avec son propre niveau d’accès, dans les limites approuvées par un administrateur.

Imaginez que vous deviez automatiser le provisionnement des utilisateurs : un service en arrière-plan met à jour discrètement les comptes utilisateurs chaque nuit. Ici, les autorisations déléguées ne servent à rien, puisque personne n’est là pour approuver l’accès. En revanche, lorsque votre solution doit proposer des fonctionnalités personnalisées pendant que l’utilisateur est actif, comme une application de signature de documents reliée à OneDrive, ce sont les autorisations déléguées qui sont pertinentes.

Dans la réalité, il est fréquent de combiner les deux approches. Savoir quel modèle correspond à votre cas d’usage est donc essentiel pour l’expérience utilisateur, la gouvernance et la sécurité. Vous ne voulez pas distribuer plus de clés que nécessaire, mais vous ne voulez pas non plus que votre service soit bloqué à 3 h du matin parce que personne n’est là pour se connecter.

Fonctionnement interne des autorisations déléguées dans Microsoft Entra : flux d’authentification et limites

Les autorisations déléguées dans Microsoft Entra ID suivent un flux d’authentification classique, piloté par l’utilisateur. Le processus commence lorsqu’un utilisateur se connecte à votre application avec ses identifiants Microsoft. À ce stade, l’application demande des autorisations spécifiques (ou scopes) et indique à l’utilisateur (et parfois à un administrateur) précisément les types de données ou d’actions auxquels elle souhaite accéder.

Si les autorisations demandées ne nécessitent que le consentement de l’utilisateur, celui-ci les approuve immédiatement via un écran de consentement. Pour les autorisations plus sensibles (comme la lecture de la boîte aux lettres de tous les membres d’une organisation), le consentement d’un administrateur est requis. Une fois le consentement accordé, votre application reçoit un jeton d’accès lié directement à l’identité de l’utilisateur et aux rôles qui lui sont attribués.

Ce jeton d’accès permet à l’application d’appeler Microsoft Graph ou les API Microsoft 365, mais elle agit toujours avec les droits de l’utilisateur. Ainsi, si l’utilisateur est un collaborateur standard, l’application ne peut pas soudainement accéder à des fonctions d’administration. Dès que l’utilisateur se déconnecte, l’accès de l’application prend fin, ce qui limite le rayon d’impact.

Mais voici la limite : les autorisations déléguées ne fonctionnent plus dans les scénarios sans surveillance. Si vous exécutez un processus en arrière-plan, une tâche planifiée ou une intégration de service qui ne doit pas dépendre d’un utilisateur connecté, les autorisations déléguées ne suffisent pas. Elles lient tout à la présence de l’utilisateur, ce qui signifie que les tâches de support, l’automatisation et les traitements nocturnes se heurtent à un mur.

Il faut aussi prendre en compte l’aspect sécurité. Si un utilisateur disposant d’un accès étendu se laisse piéger et accorde son consentement, une application pourrait détourner ces autorisations, ce qui constitue un vecteur clé des attaques par hameçonnage au consentement. C’est pourquoi vous devez contrôler strictement qui peut accorder quelles autorisations et sensibiliser vos équipes à la signification réelle de ces écrans de consentement.

Sur-autorisation des accès applicatifs et sécurité des jetons dans Microsoft Entra ID

En matière d’autorisations, plus n’est pas toujours mieux. En effet, la sur-autorisation, c’est-à-dire l’attribution de privilèges inutiles ou excessifs, en particulier avec les autorisations d’application, peut ouvrir la porte à des fuites de données sensibles et à des incidents de sécurité majeurs. Imaginez une application à laquelle vous accordez un accès en lecture et en écriture à toutes les boîtes aux lettres de l’entreprise, alors qu’elle n’a besoin que de lire les événements de calendrier : vous venez d’élargir considérablement votre surface d’attaque.

Ce danger n’est pas seulement théorique. Les attaquants exploitent l’abus de consentement OAuth pour contourner même l’authentification multifacteur. Ils ciblent les utilisateurs ou les administrateurs avec des demandes de consentement habilement conçues, pour les amener à approuver des autorisations risquées. Une fois à l’intérieur, ces applications malveillantes conservent souvent leur accès, même si les mots de passe sont modifiés ou si l’authentification multifacteur est imposée. L’emprise de l’attaquant perdure, rendant les défenses traditionnelles inefficaces. Pour une analyse concrète, consultez cette explication de la façon dont les attaquants abusent du consentement OAuth dans Microsoft Entra ID ainsi que les meilleures méthodes pour le verrouiller.

La réflexion ne s’arrête pas à la sur-autorisation. Les jetons et les identifiants, y compris les secrets client et les certificats, peuvent devenir des cibles de choix s’ils ne sont pas sécurisés. Un secret client divulgué d’une inscription d’application uniquement (app-only) suffit à un attaquant pour usurper l’identité de votre service. C’est pourquoi l’hygiène des identifiants est essentielle : utilisez des identités managées dès que possible, renouvelez régulièrement vos secrets et ne stockez jamais les identifiants client dans du code ou des fichiers non protégés. Pour les environnements qui reposent sur des accès non humains, envisagez Microsoft Entra Workload Identities, qui permettent un accès sans secret et traçable, et qui éliminent les lourdeurs des comptes de service historiques. Pour approfondir le sujet, lisez cet article sur les raisons pour lesquelles les identités de charge de travail sont indispensables au modèle Zero Trust.

Enfin, une surveillance rigoureuse n’est pas négociable. Examinez régulièrement les journaux de connexion et les autorisations OAuth accordées, configurez des alertes pour les consentements ou les usages de jetons suspects, et gardez une longueur d’avance sur l’hameçonnage au consentement et le vol de jetons. Les enseignements tirés de violations réelles (comme cette chaîne d’attaque Microsoft 365) montrent que les attaquants profitent d’une gouvernance défaillante : plus la visibilité est grande, mieux c’est. Protégez vos clés, resserrez vos autorisations et veillez à la probité de vos applications.

Contrôles et bonnes pratiques pour la gestion des autorisations déléguées et applicatives

• Mettre en œuvre les contrôles intégrés d’Entra pour la gestion des autorisationsAppuyez-vous sur les flux de consentement, les processus d’approbation par un administrateur et les stratégies affinées intégrés à Microsoft Entra pour restreindre les utilisateurs ou les groupes autorisés à accorder des autorisations. Utilisez les stratégies de consentement administrateur pour que seules les applications validées reçoivent des étendues d’accès à haut risque.
• Appliquer le principe du moindre privilègeN’accordez aux applications que le jeu minimal d’autorisations nécessaire à leur fonction. Examinez chaque autorisation demandée lors de l’enregistrement de l’application et supprimez tout ce qui n’est pas indispensable. Le moindre privilège est votre meilleure défense contre les usages abusifs et les dépassements de périmètre.
• Planifier des revues et des audits réguliers des autorisationsMettez en place des revues d’accès périodiques, à l’aide des tableaux de bord Entra consacrés aux autorisations et au consentement, afin d’identifier et de révoquer les autorisations inutilisées ou risquées. Automatisez ces contrôles dès que possible pour une gouvernance évolutive, comme le décrivent les guides de gouvernance avancée, par exemple cette stratégie Microsoft Purview.
• Surveiller les modifications d’autorisations et configurer des alertesMettez en place une surveillance et des alertes pour détecter les nouvelles attributions OAuth, les pics d’utilisation des autorisations des applications ou les intégrations d’administration inattendues. Un reporting proactif vous laisse le temps de réagir avant que les incidents de sécurité ne s’aggravent.
• Sécuriser le stockage des jetons et des identifiantsStockez les secrets client et les jetons dans des coffres sécurisés, comme Azure Key Vault. Renouvelez régulièrement les identifiants, privilégiez les certificats aux secrets partagés et préférez les identités de charge de travail pour les accès non humains, car elles offrent une meilleure gestion du cycle de vie et une meilleure traçabilité.
• Adopter une gouvernance avancée et l’automatisation des stratégiesExploitez des outils comme Microsoft Purview et Azure Policy pour imposer des contrôles à l’échelle du locataire, cloisonner les risques avec Data Loss Prevention et concevoir une conformité continue. Pour un exemple concret d’utilisation des stratégies comme fondement de la gouvernance, consultez la stratégie de gouvernance d’entreprise Azure.

En suivant ces étapes et en vous appuyant sur l’écosystème de gouvernance de Microsoft, vous permettrez à votre organisation de maîtriser les risques liés aux autorisations avant qu’ils ne deviennent des problèmes. Sensibilisez régulièrement les utilisateurs aux bonnes pratiques de consentement, automatisez chaque fois que c’est possible et gardez à l’esprit que la gestion des autorisations n’est jamais une tâche ponctuelle. Restez vigilant, affinez continuellement vos stratégies, et votre environnement Entra ID restera en bon état.

Épisodes à écouter également

Si vous explorez les autorisations déléguées et les autorisations d’application dans Entra ID, ces épisodes apportent un éclairage pratique sur l’adoption sécurisée de Microsoft 365, la protection des données, la gouvernance et la gestion des risques liés à l’IA.

• Microsoft Purview – Simply Explained — Découvrez comment la classification, la rétention, la conformité et la protection s’intègrent dans un modèle unique de gouvernance des données Microsoft.
• Microsoft Defender XDR – Simply Explained — Reliez les contrôles de protection des données à la détection, à l’investigation et à la réponse.
• Conditional Access – Simply Explained — Comprenez comment les signaux d’identité et de risque enrichissent les décisions d’accès.
• Microsoft AI Agent Harness – Simply Explained — Explorez les contrôles qui rendent l’automatisation par l’IA plus fiable, observable et sûre.

Ces épisodes vous aideront à traduire les concepts de cet article en décisions concrètes de conception et de déploiement.