The aftermaths of programming with Office 365 APIs
have been absolutely stunning. Moreover, a majority of developers have also indulged in using Office 365 APIs within the SharePoint apps. While the current state of developing apps across Office 365 and SharePoint is a bit dicey, it is vital to be familiar with the security challenges associated with the same beforehand. This is a post which makes you familiar with the correct usage of Office 365 APIs within the SharePoint apps.
The current approach followed for using Office 365 APIs within a SharePoint app
In this tutorial, I’ll be creating an app part which will read a current user’s appointments from Exchange, followed by displaying the same in SharePoint.
Getting familiar with the security challenges of using Office 365 APIs in SharePoint apps
Having created a provider hosted app project using SharePoint site in Office 365, you’ll need to open the web.config file within the remote web project to check whether a unique ClientId and ClientSecret has been assigned to the app or not. Here, ClientId and ClientSecret denote the app’s username and password respectively.
For a SharePoint app, you can opt for assigning permissions via the AppManifest.cml file which is stored in the app project. Additionally, you can use the Office 365 APIs for assigning the required permissions like the capability of reading items within the host web. Here is a screenshot for the same:
After having created the base project, you can get on with adding Office 365 API functionality by right clicking on a remote web project and selecting Add/Connected Service. A Services Manager dialog opens up, allowing you to register the app in addition to granting the permissions. For instance, here is the screenshot for granting Read permissions to user’s calendar:
After having equipped your SharePoint app with Office 365 API support, just open web.config file and check whether the new security principal has been added or not. In addition to the ClientID and ClientSecret, you’ll also be able to view idea:ClientID and ida:Password entries. The existence of two security principals is not an ideal situation. The reason being very simple. Tokens used for accessing Office 365 resources would be absolutely different from the ones used for accessing SharePoint resources. Also, the app will now prompt twice for the content- first time during app installation and the second time when the app asks user’s permission for accessing Exchange. Microsoft is making every effort to resolve this issue at the earliest and we can expect a single security principal supported across Office 365 and multiple SharePoint provider-hosted apps.
A brief on programming the application
Now, you can continue developing the app by adding an app part to the remote web. For this, simply right click the app project and select Add/New Item. Within the Add New Item dialog box, select the option “Client Web Part” and go ahead with adding a new view and controller to your MVC5 remote web app project. Now, the current user for the app will be prompted to provide his/her consent the very first time they run the application. However, since the app part runs in an IFRAME, the authorization flow doesn’t permit display of pages within the IFRAME. The only choice left is to authorize a current user in full-page app experience as an extension to caching the calendar events.
Here is the code for retrieving and caching the calendar events for the current user:
//Generate an Outlook client
OutlookServicesClient outlookClient =
new OutlookServicesClient(eventsDisco.ServiceEndpointUri, async () =>
var clientOuput = await authContext.AcquireTokenByAuthorizationCodeAsync(code, new Uri(Request.Url.AbsoluteUri.Split('?')), creds);
//Get the outputs for the next 10 hours
var eventOutputs = await (from i in outlookClient.Me.Events
where i.End >= DateTimeOffset.UtcNow && i.End <= DateTimeOffset.UtcNow.AddHours(10)
var outputs = eventOutputs.CurrentPage.OrderBy(e => e.Start);
foreach (var e in outputs)
Id = e.Id,
Body = e.Body == null ? string.Empty : e.Body.Content,
End = e.End,
Location = e.Location == null ? string.Empty : e.Location.DisplayName,
Start = e.Start,
Subject = e.Subject == null ? string.Empty : e.Subject
//cache the outputs
After the events are cached, app part would read the required data from the cache. However, if the desired data isn’t available in the cache, then the user is being redirected to app’s full-page experience for authorization purpose.
Next, there is a code for the app part, shown below:
List<MyEvent> outputList = GetFromCache("Outputs") as List<MyEvent>;
if (eventList == null)
//Redirect to app
With that, we’re done with creating a SharePoint app which uses Office 365 APIs.
Provider-hosted apps which utilize Office 365 APIs for displaying different user data are indeed the finest apps that cater to varied needs of the targeted audience. Here’s hoping the above post would have enabled you to know more about the significance of using Office 365 APIs within SharePoint apps.
Author Bio: Juana Steves is an experienced SharePoint app developer for Xicom Technologies – SharePoint Application Development Company. You can join her on Twitter to get the latest information about the SharePoint.