Azure AD App Registration - Permision request to Read and Write to “All” Site Collections too broad

Copper Contributor

When setting up an Azure App Registration for the Microsoft Graph or the SharePoint Online APIs, the only option is to grant read and write to "ALL" site collections either as delegated or app permissions.

As an ISV creating an multi-tenant application, it raises a red flag for our customer's tenant administrator granting this kind of access when we really only need access to a specific site collection. Obviously with the SharePoint Add-in (Azure ACS) model the app manifest allowed granting permission at the site level, but in our case we want to take advantage of the Graph API, Power BI, and others backed by Azure App Registration.

I can certainly log granular site collection permissions as a request on UserVoice, but I thought I would check here in case there is some manifest or querystring magic that can be done to achieve this?

13 Replies
Just checking my post here... still no answer?

@Aaron Cutlip just curious how you handled this. 

Did you use Graph api / SharePoint Online api? Or did you end up using Add-in model?

 

Graph API is the new way to go but like you said it raises a lot of red flags when you have to grant Read Write to all site collections even for internal apps built by  in house developers.

 

It has been more than an year since you posted and I don't see any responses which kinda makes me think that granular permissions is not coming anytime soon.  

Any new information on this? I'm now struggling with the same thing in my Enterprise. Does Microsoft plan on increasing granularity at all?

Yeah @Aaron Cutlip have you been able to find a work around? We are struggling with the same issue. 

If you use Delegated Permissions, the requests to SharePoint only has permission to access resources that the current user has access to... thus not actually giving them full control over all of the site collections.

e.g, You have two site collections. User A only has access to Site Collection 1. User B has access to both.

With delegated permissions, User A will only be able to interact with Site Collection 1. User B will be able to interact with Site Collection B (depending on types of permissions on that Site Collection of course)

Application permissions should only be used for applications that do not require signed-in users like background processes.

@Beau CameronWe do need application level permissions as these programs need to run in the background. The issue is that when we provide the developer with the app secret it gives them access to way more than they need.

 

We use a policy of least privileges for security reasons so this really doesn't work for us. I need to allow my developers to access an individual account, not the whole company (CEO included) through a background process.

@Jcarpenter Yea unfortunately, that's a risk of Application Permissions. That's why they require Admin approval.  

Question, If you've built the application that runs in the background for something.  Why are you sharing secrets with other devs? (Wondering what type of application this is)

@Beau Cameron  here is our scenario:

A dev comes to us and needs access to a resource through the Graph API, like checking a mailbox or uploading files to a SharePoint site automatically. I grant their request for application permissions, but now they have access to every mailbox or SharePoint site. It's not that we don't trust our devs, it's an issue of security. If that app secrete gets compromised it can now do way more damage.

@Beau Cameron Hmm... My several year old thread woke up. :)

 

The original scenario I was trying to describe is from a Partner perspective, where we are the partner and our customers have their own Office 365/SharePoint tenancy.   Our application has background processes that interact with a given (single) Site Collection and thus the need for Application Permissions.  We have been using Office Add-in/SharePoint App-Only Azure Access Control which lets us get tokens only for the single Site Collection where it has been granted, but it certainly does not feel "Modern" we would love to ditch that.   From my perspective, even if I were developing internal applications for an "Enterprise" sized company it seams like to risky of a proposition (aka crazy) not have a way to limit the scope that the App Permission has access to.   A colleague of mine mentioned maybe it would be possible to apply some kind of conditional access restrictions to the App Registration after it had been granted but this would require Azure AD premium.

 

From my perspective, the first class solution would be to allow the original App Permission grant to have a way to specify restrictions on which Site Collection(s) the grant applies. 

@Aaron Cutlip ... Thanks for you replying to this thread and updating us. This is security issue and not as much as trusting the developer. 

Have you come across a uservoice for this to lock down access to specific sites using the application permissions?

@Aaron Cutlip we are playing catch up in the Microsoft Graph team on some questions across communities here. Just FYI that StackOverflow is where we're focusing our attention and don't have resources monitoring these forums.

There is a uservoice for this which i'd encourage you to add your scenarios to and vote up. I'm also happy to chat to you directly on Teams if you wish? https://microsoftgraph.uservoice.com/forums/920506-microsoft-graph-feature-requests/suggestions/3467...

@Jeremy Thake I voted up that user voice link.  Thanks for providing that, however I am not sure that is clear enough to cover the scenario I am mentioning here.  If you do have time for a quick conversation it might help me explain what we are doing and why we chose to do it that way, which in turn helps understand why more granular permissions matter.  Shoot me an email.  Thanks, -Aaron