This post shows how to consume a Web API secured with Azure Active Directory using ADAL.js.
This post is part of a series on building a SharePoint app that communicate with services protected by Azure AD.
- Part 1 – An Architecture for SharePoint Apps That Call Other Services
- Part 2 – Using OpenID Connect with SharePoint Apps
- Part 3 – Call O365 Exchange Online API from a SharePoint App
- Part 4 – A Sample SharePoint App That Calls A Custom Web API
- Part 5 – The API Economy: Consuming Our Web API from a Single Page App (this post)
As originally proposed in the post An Architecture for SharePoint Apps That Call Other Services, changing our architecture to use a Web API affords new possibilities for our application to enable secure communication from multiple types of clients. One client for the Web API was our SharePoint app. Another client can now be a Single Page App written using Angular. Realizing there’s a ton of geekery that I’ve written on this, I put a big red arrow in the architecture diagram to show “You Are Here”.
To achieve this awesomeness, we will leverage the ADAL.js library. In fact, you’ll see we are now at the point that we don’t have to really write much code at all to make this work.
The code for this post is available at https://github.com/kaevans/spapp-webapi-exchange, including the SPA and Web API projects.
Create the Web Application
On the next page, choose Empty. This will generate a project with no content.
Change the project’s “SSL Enabled” property to True. Remember we only exchange OAuth tokens over SSL, let’s be safe out there people.
Register the SPA App with Azure AD
Go to the Azure Management Portal (https://manage.windowsazure.com), go to the Applications tab for your Azure AD tenant, and choose Add to add a new application.
When prompted, choose “Add an application my organization is developing”.
Provide a name for the new application, and set the type to “Web application and/or Web API”.
On the properties page, provide the sign-in URL for the application, which is the SSL URL that you obtained when you created the web application.
The pieces of information you primarily need are (1) the client ID and (2) the APP ID URI. The reply URL (3) and the sign-in URL (not shown) need to be updated once you deploy your application.
Scroll to the bottom of the page in the permissions section and click Add application.
In the next screen, choose your custom Web API. Note: See the previous post A Sample SharePoint App That Calls A Custom Web API for details on how the Web API is built and how it is registered with Azure AD.
Once you’ve added the application, choose the permission and click Save.
Applications in Azure AD do not use the OAuth2 implicit flow by default, you have to add that capability by editing the manifest. Download the manifest.
Change the oauth2AllowImplicitFlow value to true.
You can see where to make the change in this screen shot.
Save the file locally, then upload it to the management portal by choosing the “Upload manifest” button for the application.
Create the SPA
I am going to use the SinglePageApp-WebAPI-AngularJS-DotNet sample from the Azure AD team as a starting point. If you want more details on creating single page apps with Angular.js, go through that sample as there is some good information to be discovered there. First, I add an HTML page “index.html” and add the following markup.
Notice at the bottom of the page, we are referencing scripts in the App/Scripts folder. I add a folder, “App”, and two subfolders “Scripts” and “Views”.
I copied adal-angular.js and adal.js from the SinglePageApp-WebAPI-AngularJS-DotNet sample into the Scripts folder. I am not providing a code listing for those assets here.
Let’s add two HTML pages to the Views folder. The first, Home.html, is just used to let me know that the Angular routes are working.
The next HTML page will show our email messages.
Next I add an indexCtrl.js to handle any callbacks to the index page.
Next we need a controller to display our email messages from our custom Web API.
And finally the service that will call our custom API.
OK, that’s all our controllers and our one service. Now we need to add the app.js that initializes everything. Using the adal.js library and adal-angular.js implementation, we can simply provide the tenant and the clientId for our application. The endpoints object lets us specify an external endpoints that will be called. In this case, the Web API runs on a different port than our SPA application. Additionally, we provide the APP ID URI for the Web API application registration in Azure AD (see the previous post A Sample SharePoint App That Calls A Custom Web API for details on how the Web API is built and how it is registered with Azure AD).
The App.js file uses the “requireADLogin” property on the Angular route provider to ensure that we are first authenticated before accessing the Mail view.
To test the application, I changed the application startup projects to start just my Web API project and the SPA project.
I run the application, and it opens to the Home controller view.
Click the “My Messages” link in the navigation bar, and you are prompted to log in. This is because the route provider has the property requireADLogin set to true.
Log in, and then we can see our email message. This was a SPA application calling a custom Web API using OAuth, which then in turn calls the O365 Exchange Online API on behalf of the current user.
For More Information
OAuth Fiddler Extension – extension for Fiddler that enables you to inspect OAuth tokens.
https://github.com/kaevans/spapp-webapi-exchange – source code for this post, including the SPA and Web API projects