Consider this before granting API permissions in your Office 365 tenant
Recently, Microsoft released a preview of the ability to grant access to APIs secured with Azure AD in Office 365 tenants. Allowing developers to access these APIs is not without risks, here is why.
Building rich solutions on Office 365 just got easier
In a recent release of the SharePoint Framework, Microsoft added a new capability that allows you to more easily communicate with the Microsoft Graph and other APIs secured with Azure AD. Using the SharePoint Framework, you can easily obtain an access token to the specified API, and if you need additional permissions, you can request them too.
In comparison, previously, if you wanted to access the Microsoft Graph or an enterprise API secured with Azure AD, you had to register an Azure AD application, grant it the necessary permissions and implement ADAL JS with the OAuth implicit flow to get an access token. If your solution was a single page application things were bearable. But if you wanted to build a web part, that users could add on any page, the OAuth implicit flow implementation just became a burden.
You see, in the OAuth implicit flow, the URL is a part of the trust contract between the solution an Azure AD. The URL of your application is registered with Azure AD and the authorization flow will only complete, if the redirect URL specified during the auth flow is known to Azure AD. And with web parts, you cannot tell upfront on which pages they will be placed, which is why you can’t register them all with Azure AD and which is why you’d need a workaround. Not anymore.
Requesting additional permissions to Azure AD-secured resources
By default, Office 365 doesn’t allow access to the Microsoft Graph or other enterprise APIs secured with Azure AD. In order to access them, tenant administrators have to grant the access to the specific resources first.
But admins cannot just select which resources should be exposed to solutions. Instead, they can grant permissions only by approving permission requests. And the only way to issue a permission request at the moment, is through a SharePoint Framework solution package.
So to grant access to Microsoft Graph for example, a developer has to build a SharePoint Framework solution with the correct permission request, app catalog admin needs to deploy this solution to the app catalog, which will then provision the permission request, which can then be approved by the tenant administrator.
Two sides of SharePoint Framework permission requests
Requesting permissions through SharePoint Framework packages might seem odd at first, especially if you consider two things.
Once granted, requested permissions apply to all solutions and scripts in the tenant. So while it’s a specific solution requesting permissions, once tenant admin approves the request, all scripts in the tenant can perform the approved API operations. And it’s not just limited to the scripts you put on pages yourself. Every piece of JavaScript you load from the internet, could access these APIs too.
Also, unlike SharePoint add-ins, SharePoint Framework solutions are not bound by the permissions they request. If a SharePoint add-in needed to access the SharePoint Search API, it had to list it in its manifest or calling Search would fail. In comparison, SharePoint Framework solutions can request one set of permissions, or even none at all, and still use APIs secured with Azure AD just fine, assuming they were approved by the tenant admin.
If developers choose to consistently list permissions required by their solutions, organizations could use this information for governance of the API permissions. But how effective this model is, is highly reliable on the developers’ discipline, and there is no way to enforce it.
Custom scripts and API access
A while back already, Microsoft introduced the notion of no-script sites. If a site is designated by the admin as a no-script site, users are not allowed to put arbitrary scripts on pages. Instead, only solutions approved by admins are allowed to run.
Many users perceive no-script sites as an unnecessary hurdle in the way of productivity. But think again. Every piece of JavaScript you put on your portal, has access to all data you can access. If the user visiting the page with script on it is the tenant admin or the CEO, this script could have virtually unrestricted access to all data stored in SharePoint. And by allowing developers to access additional APIs, the risk gets only bigger. So before you start granting access to API permissions in your tenant, check twice if you have any sites in your tenant that could run arbitrary scripts.
What’s your plan
The recently released capability to allow access to resources secured with Azure AD allows developers to more easily build very powerful solutions on Office 365. But for the organizational data to remain secure, organizations need to have a plan how they will manage permission requests, track granted permissions and ensure that no arbitrary scripts could exploit the granted permissions.
At this moment, the only insight Office 365 provides you with, is the list of granted permissions. It doesn’t however tell you which solutions requested them, which solutions need them or if there are any sites which could have arbitrary scripts embedded on them and which could freely connect to these APIs.
Now that you knows what you have to do, what’s your plan?
Photo by James Sutton on Unsplash