Restrict permissions to app-only Azure AD applications consuming Office 365 services on resource level
Large organization start leveraging the Graph API to provide integrations between their third party applications and Office 365. In such companies it is common to delegate the development of integrations from the central IT organization to other business units.
The current app-only permission priviledges are not appropriate for such types of setups since there is currently no way to limit the permissions for that app to a specific resource in Office 365. This makes such use cases impossible to implement.
As an example we could consider SharePoint Online. Whever a business unit has to develop a daemon tool that exchanges data between their third party system and a SharePoint Online resource (a subset of site collections, an individual site, even a list), this cannot be done without granting them access to all SharePoint resources of that organization. This is because app-only permissions for an application are considered as an "all or nothing" type of permission for that application.
You could take a similar example with Exchange Online resources. Also in that specific case there is no way to limit the permissions to individual mailboxes.
These are the ways to implement such type of scenarios:
- Fallback to the "classic" api and authentication model (in SharePoint addin development). This has the drawback of not leveraging the Graph API. Furthermore, this type of application is unaware of conditional access mechanisms, making it a possible security thread for such organizations.
- Create a cloud identity and an application with delegated permissions. Grant to this cloud identity the necessary rights to the desired resource and then authenticate against the environment with username, password + app. This has the disadvantage of higher complexity and the need to use cloud identities, since federated identities are not working in such a scenario. The usage of a service account is also not ideal
Would be awesome to obtain a way to limit such types of applications on resource level. In theory, you could also only request an "admin consent" in case an application really requires access to all SharePoint Online resources. For such types of scenario an admin consent is not necessary required as long we are ensuring the application has access to specific resources only.
Patrick Lamber
shared this idea
Work has started. This feature is currently in preview for certain Teams resources with the name “resource-specific consent” (RSC).
Admin documentation: https://docs.microsoft.com/en-us/MicrosoftTeams/resource-specific-consent
Developer documentation: https://docs.microsoft.com/en-us/microsoftteams/platform/graph-api/rsc/resource-specific-consent
We intend to continue adding support for additional resource types in the future (e.g. SharePoint content), but we have no ETA to share at this time.
62 comments
-
Anonymous
commented
Is there any update or a viable alternative ?
I’m trying to use a third party app trigger the creation of a folder within a library. Service account is currently being used and wanted to limit this with App-Only but have just read that this approach actually broadens the security risk
-
Rojin Zerobe
commented
Can we also add this to the Create Channel endpoint of Graph?
-
Rudra Ganguly
commented
Definitely needed. We are unable to implement backend OneDrive Read/Write daemon services due to this restriction. No sane IT Security will permit access to "All" user directories/files.
-
Matt Greco
commented
Hello, we have this same issue. We want to create a bot that allows users to scan PDFs to the root of thier OneDrive, but we do not want to grant access to Sites.ReadWrite.All.
-
Jason Graham
commented
How can we get further updates for the progress on this issue? Thanks!
-
René
commented
How can we best get in touch with the team to understand what we can expect on this topic?
More and more customers deny the app-only permissions on all sitecollections, so we definitely need the possibility to fine-grain those permissons and implement sitecollection permission scoping. -
René
commented
We need to scope the app only permissions to specific sitecollections, or exclude specific sitecollections.
Maybe in combination with AIP?
Any updates?
-
Vaughan
commented
+1 on feedback for this request please. Clearly an important feature.
-
Manish Gupta
commented
Do we have any updates here?
-
Vivek Chauhan
commented
Yes we need this.
To get application permissions, we should have option to pass permission scope instead of just use /.default to request the statically configured list of permissions as mentioned in doc https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent.
-
Arjun Yadav
commented
Any update on this, specifically for MS graph directory API.
-
Satish
commented
Any update on this feature, specifically for OneDrive and TeamDrive Files. Can Microsoft share any roadmap? Is there any Early Access/Beta program where this feature is available for testing?
-
Anonymous
commented
We need this!
-
Michal Sacewicz
commented
Really looking forward to this feature being released for SharePoint.
-
Stefan Gulbrandsen
commented
When will this be ready?
-
Anonymous
commented
Yes i am waiting for this
-
Mark
commented
This applies to our scenario for MS Teams integration. We need far more granular permissions. For example, to create a group with app service requires:
Group.Create, Group.ReadWrite.All, Directory.ReadWrite.AllNo Enterprise IT dept in their right mind would grant this to an application - it exposes way too much risk. the app could delete users for example.
These permissions need far more granularity.
-
Foo Shoong Weng
commented
Hi @jackson.woods
Is there any update on this whereby we can use graph api from application to connect to restricted access to only certain online resources(eg: specified sharepoint folders/ list/ O365 mailbox but not all items)
-
Michael
commented
@jackson.woods
Has there been any progress on this? I am another very interested party.
-
Anonymous
commented
Any update on this?