Recently, Microsoft released a preview of the ability to grant access to APIs secured with Azure AD in Office 365 tenants. Giving developers permission to access these APIs contains risks for your SharePoint, here is why.
In a recent release of the SharePoint Framework, Microsoft added a new capability that allows you to communicate more easily 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 and 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 that’s why you’d need a workaround. Not anymore.
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. The app catalog admin will need to deploy this solution to the app catalog, which will then provision the permission request. The tenant administrator can then approve it.
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.
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.
The recently released capability to allow access to resources secured with Azure AD allows developers to build very powerful solutions on Office 365 more easily. But for the organizational data to remain secure, organizations need to 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 that could freely connect to these APIs.
Now that you know what you have to do, what’s your plan?
Furthermore, if you want to keep your Office 365 tenant governed at all times, check out our Customization Governance Solutions here at Rencore.
This blog post has been originally published on Waldek’s blog.