Présentation de l’accès application uniquement
Lorsqu’une application accède directement à une ressource, comme Microsoft Graph, son accès n’est pas limité aux fichiers ou aux opérations disponibles pour un seul utilisateur. L’application appelle des API directement à l’aide de sa propre identité, et un utilisateur ou une application disposant de droits d’administrateur doit l’autoriser à accéder aux ressources. Ce scénario concernant un accès application uniquement.
Quand dois-je utiliser l’accès application uniquement ?
Dans la plupart des cas, l’accès à l’application uniquement est plus large et plus puissant que l’accès délégué. Vous ne devez donc utiliser l’accès d’application uniquement que si nécessaire. Il s’agit généralement du bon choix si :
- L’application doit s’exécuter de manière automatisée, sans entrée utilisateur. Par exemple, un script quotidien qui vérifie les e-mails de certains contacts et envoie des réponses automatisées.
- L’application doit accéder aux ressources appartenant à plusieurs utilisateurs différents. Par exemple, une application de sauvegarde ou de protection contre la perte de données peut avoir besoin de récupérer des messages à partir de nombreux canaux de conversation différents, chacun avec des participants différents.
- Vous êtes tenté de stocker les informations d’identification localement et d’autoriser l’application à se connecter « en tant qu’ » utilisateur ou administrateur.
En revanche, vous ne devez jamais utiliser l’accès application uniquement lorsqu’un utilisateur se connecte normalement pour gérer ses propres ressources. Ces types de scénarios doivent utiliser l’accès délégué pour avoir les privilèges minimum.
Autorisation d’une application à effectuer des appels d’application uniquement
Pour effectuer des appels d’application uniquement, vous devez attribuer à votre application cliente les rôles d’application appropriés. Les rôles d’application sont également appelés autorisations d’application uniquement. Il s’agit de rôles d’application, car ils accordent l’accès uniquement dans le contexte de l’application de ressources qui définit le rôle.
Par exemple, pour lire la liste de toutes les équipes créées dans une organisation, vous devez attribuer le rôle d’application Microsoft Graph Team.ReadBasic.All à votre application. Ce rôle d’application permet de lire ces données lorsque Microsoft Graph est l’application de ressource. Cette assignation n’affecte pas votre application cliente à un rôle Teams qui peut lui permettre d’afficher ces données via d’autres services.
En tant que développeur, vous devez configurer toutes les autorisations d’application uniquement requises, également appelées rôles d’application lors de l’inscription de votre application. Vous pouvez configurer les autorisations d’application uniquement demandées par le biais du portail Azure ou de Microsoft Graph. L’accès d’application uniquement ne prend pas en charge le consentement dynamique. Vous ne pouvez donc pas demander des autorisations individuelles ou des ensembles d’autorisations au moment de l’exécution.
Une fois que vous avez configuré toutes les autorisations dont votre application a besoin, elle doit obtenir le consentement administrateur pour qu’elle accède aux ressources. Par exemple, seuls les utilisateurs disposant au minimum du rôle d’Administrateur de rôle privilégié peuvent accorder des autorisations liées uniquement à une application (rôles d’application) pour l’API Microsoft Graph. Les utilisateurs disposant d’autres rôles d’administrateur, tels qu’Administrateur d’applications et Administrateur d’applications cloud, peuvent accorder des autorisations liées uniquement à une application pour d’autres ressources.
Les utilisateurs administrateurs peuvent accorder des autorisations d’application uniquement à l’aide du Portail Azure ou en les créant par programme via l’API Microsoft Graph. Vous pouvez également demander un consentement interactif à partir de votre application, mais cette option n’est pas préférable, car l’accès à l’application uniquement ne nécessite pas d’utilisateur.
Les utilisateurs consommateurs disposant de comptes Microsoft, comme Outlook.com ou des comptes Xbox Live, ne peuvent jamais autoriser l’accès aux applications uniquement.
Suivez toujours le principe des privilèges minimum : ne demandez jamais des rôles d’application dont votre application n’a pas besoin. Ce principe permet de limiter les risques au niveau sécurité si votre application est compromise et permet aux administrateurs d’accorder plus facilement l’accès à votre application. Par exemple, si votre application doit uniquement identifier les utilisateurs sans lire leurs informations de profil détaillées, vous devez demander le rôle d’application Microsoft Graph User.ReadBasic.All plus limité au lieu de User.Read.All.
Conception et publication de rôles d’application pour un service de ressources
Si vous créez un service sur Microsoft Entra ID qui expose des API que d’autres clients peuvent appeler, vous pouvez prendre en charge l’accès automatisé avec des rôles d’application (autorisations d’application uniquement). Vous pouvez définir les rôles d’application pour votre application dans la section Rôles d’application de votre inscription d’application dans le Centre d’administration Microsoft Entra. Pour plus d’informations sur la création de rôles d’application, consultez Déclarer des rôles pour une application.
Lorsque vous exposez des rôles d’application que d’autres utilisateurs peuvent utiliser, fournissez des descriptions claires du scénario à l’administrateur qui va les affecter. Les rôles d’application doivent généralement être aussi étroits que possible et prendre en charge des scénarios fonctionnels spécifiques, car l’accès aux applications uniquement n’est pas limité par les droits de l’utilisateur. Évitez d’exposer un seul rôle qui accorde un accès read complet ou read/write complet à toutes les API et ressources que votre service contient.
Notes
Les rôles d’application (autorisations d’application uniquement) peuvent également être configurés pour prendre en charge l’attribution aux utilisateurs et aux groupes. Veillez à configurer vos rôles d’application correctement pour le scénario d’accès prévu. Si vous envisagez d’utiliser les rôles d’application de votre API pour l’accès aux applications uniquement, sélectionnez les applications comme seuls types de membres autorisés lors de la création des rôles d’application.
Comment fonctionne l’accès application uniquement ?
La chose la plus importante à retenir concernant l’accès aux applications uniquement est que l’application appelante agit en son propre nom et en tant que sa propre identité. Il n'y a aucune interaction avec l'utilisateur. Si l’application a été affectée à un rôle d’application donné pour une ressource, l’application dispose d’un accès sans contrainte aucune à toutes les ressources et opérations régies par ce rôle d’application.
Une fois qu’une application a été affectée à un ou plusieurs rôles d’application (autorisations d’application uniquement), elle peut demander un jeton d’application uniquement à Microsoft Entra ID à l’aide du flux d’informations d’identification du client ou de tout autre flux d’authentification pris en charge. Les rôles attribués sont ajoutés à la revendication roles du jeton d’accès de l’application.
Dans certains scénarios, l’identité de l’application peut déterminer si l’accès est accordé, de la même façon que les droits utilisateur dans un appel délégué. Par exemple, le rôle d’application Application.ReadWrite.OwnedBy accorde à une application la possibilité de gérer les principaux de service dont l’application elle-même est propriétaire.
Exemple d’accès aux applications uniquement – Notification par e-mail automatisée via Microsoft Graph
L’exemple suivant illustre un scénario d’automatisation réaliste.
Alice souhaite avertir une équipe par e-mail chaque fois que le dossier de rapports de division qui réside dans un partage de fichiers Windows enregistre un nouveau document. Alice crée une tâche planifiée qui exécute un script PowerShell pour examiner le dossier et rechercher de nouveaux fichiers. Le script envoie ensuite un e-mail à l’aide d’une boîte aux lettres protégée par une API de ressource, Microsoft Graph.
Le script s’exécute sans aucune interaction utilisateur. Par conséquent, le système d’autorisation vérifie uniquement l’autorisation de l’application. Exchange Online vérifie si l’administrateur a accordé l’autorisation d’application (rôle d’application) Mail.Send au client qui effectue l’appel. Si Mail.Send n’est pas accordé à l’application, Exchange Online échoue à la demande.
| POST /users/{id}/{userPrincipalName}/sendMail | Application cliente accordée à Mail.Send | L’application cliente n’a pas reçu Mail.Send |
|---|---|---|
| Le script utilise la boîte aux lettres d’Alice pour envoyer des e-mails. | 200 – Accès accordé. L’administrateur a autorisé l’application à envoyer des messages en tant qu’utilisateur. | 403 - Non autorisé. L’administrateur n’a pas autorisé ce client à envoyer des e-mails. |
| Le script crée une boîte aux lettres dédiée pour envoyer des e-mails. | 200 – Accès accordé. L’administrateur a autorisé l’application à envoyer des messages en tant qu’utilisateur. | 403 - Non autorisé. L’administrateur n’a pas autorisé ce client à envoyer des e-mails. |
L’exemple donné est une illustration simple de l’autorisation d’application. Le service Exchange Online de production prend en charge de nombreux autres scénarios d’accès, tels que la limitation des autorisations d’application à des boîtes aux lettres Exchange Online spécifiques.