Microsoft Graph has two parallel sets of permission scopes; Delegated & Application. Understanding the difference between the two, and when to use them, is important when it comes to optimizing your integration with Microsoft Graph and mitigating against unintentionally requesting more access than you really need (or that an IT department would wish to grant).
Delegated Permissions
To understand Delegated Permissions, its helpful to start with the dictionary definition of the word “Delegate”:
del·e·gate (verb) - To entrust a task or responsibility to another
This is precisely what Microsoft Graph means by “Delegated”, a user has delegated a given task to your application. When your application subsequently makes a call to the API, it is executing that function on behalf of the authenticated user.
The simplest illustration of Delegated Permissions in action is /me. Behind the scenes, the Graph is automatically mapping /me to the user that delegated permission to your application. Because all activities executed within a delegated scope are made on behalf of a single user, Graph is able to determine who “me” is referring to.
Activities executed using Delegated scopes are always executed on behalf of an authenticated User.
Application Permissions
Unlike Delegated scopes, Application scopes do not have a “user” in context. When your application is operating under Application scopes, your permissions are not provided by a given User but by the Azure AD instance itself.
In general, Application scopes are global. So where requesting the Delegated Mail.Read scope provides access to any mailbox the current user has permission to access, it’s Application equivalent provides access to every user’s mailbox. For this reason, you should use extreme caution before deciding to use Application scopes.
Activities executed using Application scopes are executed on behalf of your Application.
Because Application permission scopes are so broad, all Application scopes require Admin Consent before your application can access a given tenant. For this reason, they are generally not a great fit for commercial/packaged applications.
Determining Which Permissions Get Applied
Which scopes are applied to your application is determined by the OAuth Grant your use to obtain an access token. OAuth Grants that authenticate an individual receive Delegated permissions, while those that do not will receive Application permissions.
| Oauth Grant Type | Permission Type |
|---|---|
| Authorization Code Grant | Delegated |
| Implicit Grant | Delegated |
| Client Credentials | Application |
A single Access Token can only contain one type of scopes (Application or Delegated). So if your particular scenario requires both Application and Delegated scopes, your application will need to obtain two separate tokens. The first will represent the User and be obtained using an Authorization Cord or Implicit grant, the second will represent the application itself and be obtained using a Client Credentials grant.
Best Practices
- Principal of Least Privileged Permissions - An application should only request permissions that are absolutely necessary to complete the required task(s). For example: If your needs to read a user’s mailbox, you should select
Mail.Readrather thanMail.ReadWrite. - Avoid Application scopes in interactive applications - Using application permissions for interactive scenarios represents a significant compliance and security risk. They can inadvertently elevate a user’s privileges and circumvent policies configured by the tenants’ administrators. A good rule of thumb is that Application scopes should only be used for headless/daemon scenarios.