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.
56 comments
-
Anonymous
commented
I second the previous comment regarding the ability to give an appID restricted access to the GroupMember.Readwrite.All scope. Do we know if this is in scope in any of the pending roadmap items?
-
Anonymous
commented
I have a requirement to develop a web/daemon app that manipulates the member ship of specific AD groups.
Currently it seems to only be possible to give an app access to write the membership of all AD groups. (Or none at all)
Strangely this is not a popular idea with our AD admins.
Users can be given this access to specific AD groups by making them the owner.
You can even make an App’s managed identity the owner of an AD groups, but there seems to be no way to join the dots to give the app restricted access to the GroupMember.Readwrite.All scope.So I may have to resort to a service account and username/password credentials to work around this.
-
Kamal
commented
We have a problem with the Sharepoint Framework project permission. Now SPFX Web part needs Tenant (AllSites) Permission only.
when will be ETA for Sharepoint Online?
-
Anonymous
commented
I have recently hit this problem with MS Graph permissions and would love to hear about any updates that the Microsoft team have in this area of development.
-
Anonymous
commented
This would be very helpful. Any update on when we can expect this feature?
-
Anonymous
commented
It's been more than a year, please provide a status update.
-
SjoerdV
commented
Just for the sake of argument, wouldn't it be a far nicer experience if App-Only principles could fall under the regime of Conditional Access policies, just like regular users and groups? This has been suggested here as well: https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/37867180-restricting-access-of-azure-service-principals-u
This would mean that if a SharePoint site has the BlockAccess policy setting enabled and the App Principle falls under the scope of a CA policy that the access will be blocked.
-
Mark Davidson
commented
+1 on feedback for this once again. It'd be good to at least know whether this is still the direction of travel or if there has been a change of plan.
-
Jaymin
commented
Any update on this feature @Jackson.woods?
-
Bhavya Vootla
commented
+1 on feedback for this request please. Clearly an important feature.
-
James Corbishley
commented
Hi Jackson, is this something that has been integrated into the Graph API yet?
Many thanks for your time, James -
Chukiat B
commented
Any progress? Need site collection admin consent instead of tenant admin consent for specific site collection permission.
-
Anonymous
commented
+1
-
Anthony White
commented
What's the roadmap for this? Very much needed...
-
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.