Autorisations déléguées et autorisations d’application dans Microsoft Entra ID : ce que les administrateurs doivent savoir

By Mirko Peters · 2026-10-28

Découvrez les différences essentielles entre les autorisations déléguées et les autorisations d’application dans Microsoft Entra ID, avec les bonnes pratiques de sécurité et les règles du moindre privilège.

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

Lorsque vous intégrez des outils tiers ou des applications personnalisées à votre environnement Microsoft 365, comprendre la différence entre autorisations déléguées et autorisations d’application est essentiel pour préserver la sécurité du cloud, prévenir les fuites de données et appliquer le principe du moindre privilège au sein de Microsoft Entra ID.

Points clés

• Les autorisations déléguées nécessitent un utilisateur connecté et agissent en son nom : l’application ne peut donc accéder qu’aux données que cet utilisateur est autorisé à consulter.
• Les autorisations d’application fonctionnent sans utilisateur humain, accordent un large accès à l’ensemble du locataire et nécessitent l’approbation d’un administrateur.
• Le principe du moindre privilège veut que les applications ne reçoivent jamais que le plus petit ensemble d’autorisations nécessaire à l’accomplissement de leur tâche.
• Microsoft Graph fait office de point d’accès unifié aux données de Microsoft 365 et repose largement sur ces modèles d’autorisations.
• Comprendre cette distinction permet d’éviter de graves failles de sécurité, comme l’octroi involontaire d’un accès à l’ensemble du locataire à des applications tierces.

Comprendre les autorisations OAuth dans le cloud Microsoft

Lorsque vous connectez un outil de productivité externe ou un script d’automatisation interne à votre espace Microsoft 365, vous déclenchez un flux OAuth 2.0 sous-jacent. Toutefois, obtenir un jeton d’accès ne représente que la moitié du chemin. La véritable limite de sécurité est définie par ce que ce jeton est effectivement autorisé à faire. Dans l’écosystème d’identité Microsoft, centré sur Microsoft Entra ID (anciennement Azure Active Directory), les autorisations se répartissent en deux catégories fondamentalement différentes : les autorisations déléguées et les autorisations d’application.

Confondre ces deux modèles est l’un des pièges les plus fréquents pour les administrateurs informatiques, les développeurs et les utilisateurs avancés. Choisir le mauvais type d’autorisation peut exposer par inadvertance des données de l’entreprise entière, ou tout simplement casser le fonctionnement de l’application. Voyons comment fonctionne chaque type, où il est défini et comment le gouverner correctement.

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

Les autorisations déléguées sont conçues pour les applications utilisées par une personne. Lorsque vous vous connectez à une application mobile ou à un service web avec votre compte Microsoft, l’application emprunte votre identité pour un ensemble précis de tâches. C’est ce que l’on appelle une autorisation déléguée.

Dans ce scénario, l’application agit en tant que vous. Elle ne peut accéder qu’aux données auxquelles vous avez déjà le droit d’accéder, et rien de plus. Si votre compte utilisateur n’a pas l’autorisation de lecture sur un dossier SharePoint particulier ou sur l’agenda d’un collègue, l’application ne pourra pas non plus y accéder. Comme le périmètre d’impact est naturellement limité par les autorisations de l’utilisateur, Microsoft recommande d’utiliser les autorisations déléguées chaque fois qu’une personne est impliquée dans le flux de travail.

Comment les autorisations déléguées apparaissent en pratique

Vous rencontrez des autorisations déléguées à chaque fois que vous cliquez sur une invite de consentement. Un assistant de planification peut par exemple afficher un écran indiquant qu’il souhaite lire votre agenda. Cette demande correspond à une étendue OAuth précise. Comme vous êtes présent pour approuver ou refuser la demande, vous agissez en tant que propriétaire de la ressource et contrôlez précisément ce que l’application cliente est autorisée à emprunter à votre profil.

Autorisations d’application : services en arrière-plan et accès à l’ensemble du locataire

Les autorisations d’application fonctionnent selon un paradigme entièrement différent. Elles sont conçues pour les démons en arrière-plan, les scripts de synchronisation automatisés et les services back-end qui s’exécutent à trois heures du matin, lorsqu’aucun utilisateur n’est connecté. Pensez à un outil de reporting automatisé qui agrège les données de toutes les boîtes aux lettres de l’organisation.

Comme aucun utilisateur n’est présent pour fournir un contexte d’identité, l’application s’authentifie à l’aide de ses propres informations d’identification (comme un ID client et un secret client, via le flux d’informations d’identification client). Par conséquent, les autorisations d’application permettent à l’outil d’agir en son propre nom dans l’ensemble de l’organisation. Si une application dispose de l’autorisation d’application de lire les courriers, elle peut lire la messagerie de chaque utilisateur du locataire.

Pourquoi le consentement administrateur est obligatoire

Compte tenu de la puissance considérable associée aux autorisations d’application, les utilisateurs standard ne peuvent pas y consentir. Si un employé standard peut approuver une autorisation déléguée pour son propre agenda, les autorisations d’application exigent l’approbation explicite d’un administrateur général ou d’un administrateur de rôle privilégié. Ce filtrage strict empêche les applications malveillantes ou mal conçues de collecter discrètement des données à l’échelle de l’organisation.

Microsoft Graph et le rôle des étendues OAuth

Qu’une application utilise des autorisations déléguées ou d’application, elle dirige en fin de compte ses requêtes vers une passerelle unique et puissante : Microsoft Graph. Chaque conversation Teams, chaque document SharePoint, chaque fichier OneDrive et chaque courriel Outlook est accessible via Microsoft Graph, à condition que l’application appelante présente un jeton d’accès OAuth valide.

Les garde-fous qui garantissent l’intégrité de ces jetons s’appellent les étendues. Une étendue est un libellé précis intégré au jeton, qui définit des limites exactes, comme la lecture d’un agenda ou l’envoi d’un courriel. Lorsque les développeurs demandent des étendues trop larges (par exemple un accès en lecture et en écriture alors que la lecture seule suffirait), ils enfreignent les principes fondamentaux de la sécurité. Les administrateurs doivent auditer ces étendues avec soin lors des revues d’inscription des applications.

Appliquer le moindre privilège dans votre locataire

Les bonnes pratiques de sécurité dans Microsoft Entra ID se ramènent toujours à une règle d’or : le principe du moindre privilège. Chaque application, chaque entité de service et chaque script d’automatisation ne doit se voir accorder que le niveau d’accès strictement nécessaire à l’accomplissement de sa tâche.

• Privilégiez systématiquement les autorisations déléguées aux autorisations d’application dès qu’un utilisateur interagit avec l’application.
• Examinez attentivement les demandes de consentement afin de vous assurer que les applications ne demandent pas d’étendues inutiles.
• Passez régulièrement en revue les applications d’entreprise enregistrées dans Microsoft Entra ID afin de révoquer les jetons orphelins et de supprimer les inscriptions d’applications inutilisées.
• Assurez une supervision administrative de tout flux d’informations d’identification client fonctionnant dans des environnements sans interface.

Conclusion

Comprendre le fonctionnement de l’identité cloud moderne exige de dépasser les simples boutons de connexion pour examiner les structures d’autorisations sous-jacentes. Que vous gériez des applications mobiles destinées aux utilisateurs avec des étendues déléguées ou d’importantes automatisations d’entreprise reposant sur des autorisations d’application, connaître ces limites est indispensable pour un environnement Microsoft 365 sécurisé.

Pour approfondir les fondements du fonctionnement de ces échanges, écoutez l’épisode complet du podcast, qui présente de façon accessible OAuth 2.0, le cycle de vie des jetons et les quatre acteurs de chaque échange.

Questions fréquentes

Les utilisateurs standard peuvent-ils approuver des autorisations d’application dans Microsoft Entra ID ?

Non. Les autorisations d’application fonctionnent sans utilisateur connecté et ont une portée à l’échelle du locataire. Seul un administrateur disposant des droits appropriés sur le locataire peut donc accorder des autorisations d’application.

Que se passe-t-il si un utilisateur tente d’accéder à un fichier via une application disposant d’autorisations déléguées, alors qu’il n’a pas les droits sur ce fichier ?

L’application se verra également bloquer l’accès à ce fichier. Les autorisations déléguées empruntent l’identité de l’utilisateur, ce qui signifie que l’application ne peut jamais dépasser les limites d’accès personnelles de l'utilisateur.

Quel est le principal risque de sécurité lié aux autorisations d’application ?

Les autorisations d’application font fonctionner des services en arrière-plan sans supervision humaine : un identifiant d’application compromis peut donc accorder à un attaquant un accès illimité aux boîtes aux lettres, aux fichiers et aux ressources de l’entreprise.

Comment Microsoft Graph interagit-il avec les jetons OAuth et les autorisations ?

Microsoft Graph sert de passerelle d’API pour Microsoft 365. Chaque requête adressée à Graph doit transporter un jeton d’accès OAuth qui intègre des étendues précises définissant des autorisations déléguées ou des autorisations d’application.