{"id":2054,"date":"2018-11-11T11:00:30","date_gmt":"2018-11-11T11:00:30","guid":{"rendered":"https:\/\/developer.microsoft.com\/en-us\/office\/blogs\/?p=2054"},"modified":"2018-11-11T11:00:30","modified_gmt":"2018-11-11T11:00:30","slug":"30daysmsgraph-day-11-azure-ad-application-permissions","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/microsoft365dev\/30daysmsgraph-day-11-azure-ad-application-permissions\/","title":{"rendered":"30DaysMSGraph \u2013 Day 11 \u2013 Azure AD application permissions"},"content":{"rendered":"

List of all posts in the #30DaysMSGraph series<\/a><\/p>\n

In Day 10<\/a> we discussed Azure AD applications created through the V1 endpoint.\u00a0 Today we’ll look at the permissions available and how to assign them to a user \/ Azure AD application.<\/p>\n

\"\"<\/p>\n

Types of permissions<\/h2>\n

Accessing Microsoft Graph endpoints requires that the application and \/ or user making the request has the appropriate permissions assigned.\u00a0 These permissions can be one of two types: delegated permissions<\/strong> or application permissions<\/strong>.<\/p>\n

\"\"<\/p>\n

Delegated (on behalf of)<\/h3>\n

Delegated permissions, sometimes called “on behalf of” permissions, require a user context to also be supplied when making the request.\u00a0 In effect an application is making Microsoft Graph requests on behalf of the user.\u00a0 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.<\/p>\n

The logical intersection of these two results in the effective permissions<\/u> used when making requests.\u00a0 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.<\/p>\n

If you are decoding an access token (see Day 8<\/a>), delegated permissions will show up as “scopes” within the decoded claims.\u00a0 Checking that the access token has the appropriate \/ expected “scopes” is a good first step to ensure that permissions are assigned and consented.<\/p>\n

 <\/p>\n

Application (app-only or “without a user”)<\/h3>\n

Application permissions, sometimes called app-only or “without a user”, run without a user context.\u00a0 Common examples of this would be a background service or a daemon application.\u00a0 Only the permissions granted to the application will be evaluated when Microsoft Graph request is made.<\/p>\n

Typically an Azure AD domain administrator needs to grant consent for the application permissions requested.\u00a0 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.\u00a0 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.\u00a0 Read more about available roles\u00a0for Administrator role permissions in Azure Active Directory<\/a>.<\/p>\n

If you are decoding an access token (see Day 8<\/a>), application permissions will show up as “roles” within the decoded claims.\u00a0 Checking that the access token has the appropriate \/ expected “roles” is a good first step to ensure that permissions are assigned and consented.<\/p>\n

 <\/p>\n

Permission naming pattern<\/h3>\n

All permissions within Microsoft Graph have an internal name that follows a specific pattern:<\/p>\n