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. We plan to build an experience where end users and administrators can pick a specific resource to grant consent to, such as a specific group or site. This will be programmable through Microsoft Graph API.
25 comments
-
Maarten Visser
commented
The only way to stop Shadow IT (buying SaaS apps not landing in M365) is by having mechanisms for End Users (with no more then SP Site (Collection) Admin rights) to be able to install Apps from AppSource WITHOUT the need to go to Corporate IT. So no need for Tenent wide Consent, App Catalog approvals or other actions which require Azure AD or SharePoint Admin rights.
We need this! And any other option to have a smooth flow for onboarding customers (SPfx and Team Tab apps)
-
Daniel Flath
commented
We are a large organization in Germany and also need this feature. We have many third-party applications which are developed only with app permissions in scope.
Currently we can't use any of these applications because of the security impact of granting application permissions.
Especially for applications which collect data in the background it's much easier to use application permissions for a good reason. But we need to make sure to scope the permissions only to those resources needed and not to "all" information in the tenant. -
Martin Kolb
commented
Especially for germany this has a huge impact, since I am not able to get a consent for an app permission that can read all private calendar events of everyone in the organization. The work councils of our customers will never allow such a piece of code.
The administrator needs to have the granular option to restrict permissions on a calendar similar to delegated permissions on a shared calendar (free busy / title only / … ).
Currently, we are running with a service account, but this has bad side effects: It consumes an exchange online license, and currently it's not possible to create Graph subscriptions for shared calendars within the user context.Thanks in advance!
-
Jim
commented
I am looking forward the restriction of app permissions. Usually, in real world, app read/write whole company/organization's data is not accept by admin and i really understand admin since nobody likes exposing his emails/calender/tasks to a "unkonw" app for him.
-
Toni Pohl
commented
If my app gets permission to access "calendar write", I can modify ALL mailbox calendars.
Large organizations would love to restrict Apps just for specific objects, like my app only can write to calendars of users *@contoso.com or of users that are member of security group "Contoso" or similar...
Any plans on that topic?