What is the difference between API Permissions in the App Registration and the Role Assignments that can be given to the Service Principle? For Azure Storage, the only available permission is User Delegation. I can also provide a role based access for the application's service principle. What is the difference in behaviour here? Does one override the other? Or is it supplemented by the other?

Hello @Somansh Reddy API Permissions: You should configure API Permissions when you would like to return the permissions in the Access token. When application consumes the token, it makes authorization decision on the basis of permissions present in the token. Delegated permissions are used when authentication is done under user's context and are returned in scope claim of the token. Application permissions are used when authentication is done under application (service principal) context and are returned in roles claim. For example, if you have a web application, you can configure it to allow access to the user if scope claim contains read otherwise deny access or grant write access to application only when roles claim contains write. Role Assignments: Role assignments are used to assign permission to users/service principals on Azure Resources. In this case authorization is done by Azure and not by the end application which happens in case of API permissions. To configure application permissions, app roles must be added to app manifest as shown below: However, Azure Storage API is exposed on an app registered in Microsoft tenant and you cannot configure the application permissions by updating app manifest. Which is why the application permissions are not available for Azure Storage API. You can however configure permission via Role Assignment to application (service principals) over Azure Storage. You can configure both permissions simultaneously as these permissions are evaluated at different places (as mentioned above) and one doesn't override the other. ----------------------------------------------------------------------------------------------------------- Please " Accept the answer " if the information helped you. This will help us and others in the community as well.

API Permissions vs Role Assignments for App Registration in Storage Accounts

Accepted answer

AmanpreetSingh-MSFT 56,311 Reputation points

2020-08-31T15:25:30.517+00:00

Hello @Somansh Reddy

API Permissions: You should configure API Permissions when you would like to return the permissions in the Access token. When application consumes the token, it makes authorization decision on the basis of permissions present in the token. Delegated permissions are used when authentication is done under user's context and are returned in scope claim of the token. Application permissions are used when authentication is done under application (service principal) context and are returned in roles claim. For example, if you have a web application, you can configure it to allow access to the user if scope claim contains read otherwise deny access or grant write access to application only when roles claim contains write.

Role Assignments: Role assignments are used to assign permission to users/service principals on Azure Resources. In this case authorization is done by Azure and not by the end application which happens in case of API permissions.

To configure application permissions, app roles must be added to app manifest as shown below:

However, Azure Storage API is exposed on an app registered in Microsoft tenant and you cannot configure the application permissions by updating app manifest. Which is why the application permissions are not available for Azure Storage API. You can however configure permission via Role Assignment to application (service principals) over Azure Storage.

You can configure both permissions simultaneously as these permissions are evaluated at different places (as mentioned above) and one doesn't override the other.

-----------------------------------------------------------------------------------------------------------

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.
Please sign in to rate this answer.

2 people found this answer helpful.
Somansh Reddy 136 Reputation points

2020-08-31T20:24:45.313+00:00

@AmanpreetSingh-MSFT

Let's say that I have an application that I am building. This would be the 'client application' if I understand the terminology correctly. And let's say that I wish to access some Azure resource. As far as I understood, we have two options.

1) Allow a user to sign in through my application, and then I would be able to authorize requests to the resources on behalf of the user.
2) My application itself acts as an identity that has permissions. And based on the permissions granted to my 'client application', I can access resources.

Are the above two statements correct?

And when we talk about API permissions, I assume it is the permissions we require to access some API 'from' the client application. This API can be a Microsoft API or some other API exposed on Azure.

AmanpreetSingh-MSFT 56,311 Reputation points

2020-09-01T11:24:34.187+00:00

Hello @Somansh Reddy Yes, the two statements are correct. Just to avoid any confusion, I have tried to explain it with an example below:

You added User.Read Graph API permission as delegated permission via API Permissions blade to your client application, registered under Azure AD App Registration. This will allow Graph API to read all users from Azure AD on behalf of signed-in user, where the Audience in the user's access token will be the APP ID of your client app.

You added this permission as Application Permission, this will allow Graph API to read all users from Azure AD on behalf of your client app. Again audience in the access token should be the APP ID of your client app.

Somansh Reddy 136 Reputation points

2020-09-01T20:57:53.123+00:00

@AmanpreetSingh-MSFT And what is the difference if we use Azure AD role assignments here?

AmanpreetSingh-MSFT 56,311 Reputation points

2020-09-02T14:21:25.533+00:00

Hello @Somansh Reddy Azure AD role assignments are not application specific. E.g., if you assign Directory Readers directory role to a user, any request made under that user context via any application can be used to read directory objects. These permissions are used in conjunction with API permissions if both permissions are applicable.

Somansh Reddy 136 Reputation points

2020-09-02T21:13:41.2+00:00

@AmanpreetSingh-MSFT Okay, so for the Azure Storage case, if I want a client application to access resources on behalf of itself ( because some operations happen in the background so I cannot have a signed in user ), then just giving it an Azure role would be sufficient. I need not give it User Delegated API Permission because there are no users involved, right?

AmanpreetSingh-MSFT 56,311 Reputation points

2020-09-03T09:23:47.733+00:00

@Somansh Reddy Yes, that is correct.

Somansh Reddy 136 Reputation points

2020-09-03T15:22:33.747+00:00

And what would be the difference of using Single tenant vs Multi-tenant if I am going for the above method of authentication? Using a service principle for my client appication with client credentials authentication so there is no signed in user. Since my application is using Microsoft resources without any user, I think having it as single tenant or multi-tenant makes no difference?

AmanpreetSingh-MSFT 56,311 Reputation points

2020-09-04T12:10:51.09+00:00

@Somansh Reddy In case of multi-tenant applications, Users or Global Admin (based on the configuration) in the other tenant needs to provide consent at first time application access so that a corresponding service principal gets created in their tenant which is not possible when we authenticate using client credentials flow as it is non-interactive auth. So in this case, regardless of whether you choose single tenant or multi-tenant, the authentication can be done in single tenant only, which is the tenant where the application is registered.

Somansh Reddy 136 Reputation points

2020-09-04T12:45:53.617+00:00

@AmanpreetSingh-MSFT

Two questions here:

1) If the Admin gives consent upon first time application access, then it creates a service principal. Now do we need subsequent log in for the admin? Or can the Admin assign a role to the Service Principal for access to Azure Storage, and then the app keeps accessing that?
.
2) Maybe client credentials is not the correct authentication for my use case. Let me be more specific.

My client application ( hosted on a web server which is not on Azure ), needs to access Azure Storage accounts for various Organizations. Say there are three Organizations - Org1, Org2 and Org3. I would have one instance of my application running on my server for each of these 3 Organization, so basically they are isolated instances. There would be a UI based form for an Organization to enter their details ( Like subscription id, storage account name etc ).

Somansh Reddy 136 Reputation points

2020-09-04T12:46:22.307+00:00

I was under the impression that I have two options.

Option A - Create an app registration in each Organization. So there would be 3 apps created ( one in each of the Organization's tenant ). Each Organization would have to give their respective app's service principal a role to be able to access their Storage Accounts. So 3 apps and 3 service principals in total.

Option B. Create an app registration in my Organization ( tenant ). For ease of understanding let us call this SomanshOrg.
Can we create a service principal in Org 1, Org2, Org3 where each Organization would have to give their respective app's service principal a role to be able to access their Storage Accounts. And then from my client application I would be able to access their resources. So 1 app and 4 service principals ( 3 Org + mine ) in total.

The end goal is to only take credentials from the User in the initial UI form. And then we can access their Azure Storages without any more user involvement.

Somansh Reddy 136 Reputation points

2020-09-09T18:45:27.297+00:00

@AmanpreetSingh-MSFT ?

andrei 45 Reputation points

2024-02-07T11:06:59.7566667+00:00

@Somansh Reddy Hello! Did you find a solution for your use case? I'm trying to figure out how to resolve the very same use case: I have a multi tenant application and I want this app (which is registered in my tenant, the so called 'home' tenant) to be used by multiple clients to access some of their resources in their subscription. So far the solution I've found (please first checkout multitenant app authorization using oauth2 to better understand) is to ask for the following scopes to the client who will run the app: 'https://management.azure.com/user_impersonation' To give you an example (python code) if you use DeviceCodeCredentials: credentials = DeviceCodeCredential( client_id=<your-multitenant-app-client-id>)

credentials.authenticate(
scopes=[ 'https://management.azure.com/user_impersonation' ]
) This works ok, as it will create a service principal in the client tenant which will basically have the user_impersonation rights over the user who grant permission to my app. BUT THIS IS BAD because I want to fine set the service principal permissions in a more granular way. Imagine the user who granted consent has some very sensitive admin rights, that would make my service principal (linked to my app) very powerful BUT i don't want this. I want to fine set the permissions to exactly what my service principal needs. Somebody knows how do I do this?
Sign in to comment

API Permissions vs Role Assignments for App Registration in Storage Accounts

0 additional answers