Menu Close

Modular SharePoint authentication using Logic Apps/Flow

Whether you’re using Azure Logic Apps or Microsoft Flow you may have already stumbled upon the “Send an HTTP request to SharePoint” action on both. While this seems like a pretty good solution for working with the SharePoint API (still necessary sometimes as out-of-the-box actions can’t handle everything the API can) authentication should be considered as this action relies on the SharePoint connector and therefor connects through a user account. Obviously, this option has some downsides, the first being the need for a user account having all sorts of SharePoint rights and licenses needed. Secondly every action will run under this users name and will be shown throughout SharePoint for the results of those actions.

Is there another option for authentication? Yes, there is! Namely the SharePoint Add-in option where you register an App Service Principal you can use in Azure Logic Apps and Microsoft Flow to request an access token, which in turn can authenticate SharePoint API calls. You most certainly don’t want to invent the wheel over and over again so we’re going to create an ‘access token module’ for usage throughout your entire scope of Azure Logic Apps or Microsoft Flows.

I’m going to lead you through all steps necessary, being:

Well, come on then. Let’s go and create one!

Setting up the SharePoint Add-in

First things first. A SharePoint Add-in should be registered in your Site Collection. This can be done by forming your URL like the one below:

<Site Collection URL>/_layouts/15/AppRegNew.aspx

You’re shown a screen where can generate a Client id and a Client Secret. You can choose to create your own secret, but for this example I’m going to let SharePoint generate one for me. However, be careful with an automatically generated Client Secret as they break authentication when containing a + sign. If you get one click generate again until you receive a ‘clean’ version.

Give your SharePoint Add-in a recognizable name and set the App Domain and Redirect URI to respectively localhost and https://localhost. For this particular case it doesn’t actually mind what you enter here.

Once you’ve registered a SharePoint Add-in it doesn’t have any permissions by default. To set them we need navigate to:

<Site Collection URL>/_layouts/15/AppInv.aspx

On this page you can lookup your newly created SharePoint Add-in after which most of the fields are automatically filled. In this example I’m going to set managing rights at the Site Collection level using the XML below:

<AppPermissionRequests AllowAppOnlyPolicy="true">
<AppPermissionRequest Scope="http://sharepoint/content/sitecollection" Right="Manage" />

Off course several options are available for settings permissions for SharePoint Add-ins. Find your desired set in the Microsoft Docs article ‘Add-in permissions in SharePoint’. You can also combine permission sets.

Now hit Create and click Trust it afterwards for the permission to become effective.

Congrats! You’ve just created a SharePoint Add-in. Let’s continue!

Create the authentication module

Now we’ve got our means of authentication ready for action it’s time to let it fly. In this example we’re doing so by creating an authentication module which can be reused in other places. That way we don’t have to set up authentication every time we’re in need of working with the SharePoint API.

It begins either in Azure Logic Apps or Microsoft Flow with creating an HTTP trigger used to kick off the process of requesting an Access Token from other places. I want to set the Method to GET as it feels like the logical choice since we want to ‘get an access token’ when calling this module.

Next we add a Parse JSON action where we enter the settings necessary for the Token API. With parsing we can easily reuse these parameters while creating the following actions. The clientId and clientSecret were generated during the previous step. Your tentantId can be found by accessing the Azure Portal and browsing to Azure Active Directory > Properties > Directory ID (this is your tenantId). The same JSON can be used as sample payload to generate the schema.

Because it’s impossible still to copy/paste from an image I’ve pasted the JSON used below. For the record, the resourceId is always 00000003-0000-0ff1-ce00-000000000000. Nerd fact: if you look close it reads Office 😉

	"tenantid": "<tenantId>",
	"clientId": "<clientId>",
	"clientSecret": "<clientSecret>",
	"resourceId": "00000003-0000-0ff1-ce00-000000000000",
	"hostname": "<tenantName>",
	"at": "@"

Okay, so we’ve got our parameters ready. Let’s form the Token API request. First we’re going to set the Method to POST, point the URI to (the double slash is no accident!) and put a Content-Type header in place with value x-www-form-urlencoded. The body of this action is formatted as follows:


Your action should look something like:

The only thing left is to give a 200 response containing the Access Token for the caller to be able to reuse it. So, in the Response action Body we post the Body of the previous action, which holds the Access Token (among others).

You can test your module by entering the URL of the HTTP trigger in an application like Postman. If your response looks somewhat like the one below you’re all set! You can use the JSON response as a sample payload again to generate the schema in the Azure Logic Apps and/or Microsoft Flows where you’re using going to use this module (for security reason you may want to sanitize the JSON response before sharing with others by emptying the resource and access_token).

And that is that. Let’s see the module in action!

Use the module in other places

Now we’ve got the authentication module in place we can simply call it whenever we got the need for using the SharePoint API, for which we need authentication. Simply create an HTTP action, set the Method to GET and paste your module’s URL (derived from it’s HTTP trigger) in the URI field.

The response can be parsed by a Parse JSON action by adding the Body of the previous action to the Content field. As mentioned before this action results in parameters for easy reuse in other actions. At the end of the last step we already received a response using Postman which can be used as sample payload to generate the schema.

Last thing we need to do is add another HTTP action being the one who’s actually firing the request to the SharePoint API. You can enter any SharePoint API URI here, but for this example I’m going to use:

<Site Collection URL>/_vti_bin/listdata.svc/Documents

I’m using the URI above with the Method set to GET which will result in listing the documents on this particular Site Collection. I’ve added an Accept header with value application/json;odata=verbose and an Authorization header where the parameters token_type and access_token are added as value. These two are seperate by a space since this is needed to form the token correctly.

And there you go! You have now successfully created an authentication module for the SharePoint API using Azure Logic Apps or Microsoft Flow, and used it to collect a list of documents.

Next time I will dive deeper into the matter of authenticating to the SharePoint API and how to make this module even more modular. I’m very curious to your experiences of working with Azure Logic Apps and/or Microsoft Flow, and perhaps some other topics you’d like me to discuss!

Share a bit of yourself

%d bloggers like this: