It’s well documented in the Permissions and consent docs and the Developer Glossary page that there are 2 types of permissions for an access token: delegated permission and application permission. In simpler terms, delegated permission is the permission granted to a signed in user while application permission is the permission granted to an application. The main difference between the two is that the former requires a user to sign in while in the latter, there is no user and the application authenticates to Azure AD using its own application identity (client id and secret/assertion)

Regardless of permission type, these API permission will have to be configured in In Azure AD’s App Registration portal under API permissions blade:

Note: When configuring Application Permission, admin consent will also need to be granted for the permission to work.

Authentication Flow:

Azure Active Directory supports different OAuth2 authentication flows. The kind of authentication flow an application uses will result in a particular types of permission in an access token.

Application permission token can only be obtained from the following flow:

• Client credentials grant

Delegated permission token can only be obtained from the following flow:

• Implicit grant flow
• Authorization Code grant flow
• On-behalf-of flow
• Device code flow
• Resource owner password credentials grant flow

I have an access token. How can I tell if this token is delegated permission or application permission?

Use https://jwt.ms to look at the token claims.

For application permission token, the permissions are in the “roles” claim:

Note:  the “scp” claim is not available for application permission

For delegated permission token, the permissions are in the “scp” claim instead

Note:  the “roles” claim still may be present in the delegated permission and they contain the roles the user is assigned to in the API app.

It’s important to understand what permission type the API supports

I have seen a plethora of 400s, 401s, 403s, and 500s error due to the application calling different APIs (Azure AD Graph, Microsoft Graph, PowerBI, etc…) with the wrong permission type token. For an API, different REST end point operation may require different permission type. Always refer to the documentation for the API end point to see what permission type is supported. You will also need to assess if the authentication flow used will yield the desired permission type token. Below are a couple of example:

1. List trustFrameworkPolicies – https://docs.microsoft.com/en-us/graph/api/trustframework-list-trustframeworkpolicies?view=graph-rest-beta&tabs=http. Calling this REST end point requires a delegated permission token. Application permission token will not work.

   

2. Power BI API – although Power BI supports both delegated and application permission, application permission token is very limited in what it can do. Common task like viewing Power BI reports (which would require Report.Read.All permission) can only be done with a delegated token. In the App Registration portal, Power BI Application permission only supports the following 2 permission: Tenant.Read.All and Tenant.ReadWrite.All

   

While its counter part delegated permission is a much richer feature set:

What about Microsoft Graph Explorer?

I have often seen customers running into issues with calling Microsoft Graph REST endpoint. They try the Graph request in MS Graph Explorer and it works while the same request fails in their application. There are a few things one can look into:

• MS Graph Explorer will always use delegated permission token. Check to see what permission type the token has
• Is the same user account used to log into both MS Graph Explorer and the application?
• Does the endpoint support delegated permission, application permission, or both?
• Does the token have the correct permission to call the end point?

I hope this post is helpful in helping you diagnose the problem better