List of all posts in the #30DaysMSGraph series
In Day 10 we discussed Azure AD applications created through the V1 endpoint. Today we’ll look at the permissions available and how to assign them to a user / Azure AD application.
Types of permissions
Accessing Microsoft Graph endpoints requires that the application and / or user making the request has the appropriate permissions assigned. These permissions can be one of two types: delegated permissions or application permissions.
Delegated (on behalf of)
Delegated permissions, sometimes called “on behalf of” permissions, require a user context to also be supplied when making the request. In effect an application is making Microsoft Graph requests on behalf of the user. As such, the required permissions will be a combination of 1) what the user has permissions to do and 2) what the application has permissions to do.
The logical intersection of these two results in the effective permissions used when making requests. If the application has been granted permissions (ex. read all user info from Azure AD) that the user has not been granted, then the application will not be able to complete that specific request.
If you are decoding an access token (see Day 8), delegated permissions will show up as “scopes” within the decoded claims. Checking that the access token has the appropriate / expected “scopes” is a good first step to ensure that permissions are assigned and consented.
Application (app-only or “without a user”)
Application permissions, sometimes called app-only or “without a user”, run without a user context. Common examples of this would be a background service or a daemon application. Only the permissions granted to the application will be evaluated when Microsoft Graph request is made.
Typically an Azure AD domain administrator needs to grant consent for the application permissions requested. However, there is a new Azure AD role called Application Administrator that is able to consent to delegated permissions for Azure AD apps, and applications permissions excluding Microsoft Graph and Azure AD Graph. For the purposes of this blog series that may not be suitable given the Microsoft Graph exclusion but it is worth noting for other scenarios. Read more about available roles for Administrator role permissions in Azure Active Directory.
If you are decoding an access token (see Day 8), application permissions will show up as “roles” within the decoded claims. Checking that the access token has the appropriate / expected “roles” is a good first step to ensure that permissions are assigned and consented.
Permission naming pattern
All permissions within Microsoft Graph have an internal name that follows a specific pattern:
- Resource.Operation.Constraint
Ex. User.Read.All = Read permission for all users in the current directory.
The resource and operation will always be specified, but the constraint is optional and defines the potential scope within the service / directory. If the constraint is not listed, then the permission applies to the resources for the currently logged in user.
Ex. User.Read = Read permission for the currently logged in user.
For a full listing of all permissions grouped by resource please refer to the Microsoft Graph permissions reference. See the following screenshot for an example of the permissions required for a given operation on the Microsoft Graph.
Note: Permissions required are listed from least privileged to most privileged. In general it is a best practice to request / consent the least privilege necessary to accomplish a task. Ex. User.Read is preferred to User.ReadWrite. If, however, the application needs both User.Read and User.ReadWrite then both could be satisfied with User.ReadWrite alone.
Try It Out
Navigate to the Microsoft Graph API reference.
- Find an operation that you would like to complete and identify the permissions required for that operation.
Join us tomorrow as we look at authentication flows for Microsoft Graph requests in Day 12.
