Integrating AngularJS with Azure Active Directory and Office 365/SharePoint, Part 1

Dan WahlinSpike Xavier

by Dan Wahlin, Spike Xavier on 10/9/2014

Share this:

Article Details

Date Revised:

Applies to:
AAD, Angular JS, Azure Active Directory, Office 365, SharePoint

Sponsored by

The Microsoft Office 365 team is the sponsor of this series.

Data is everywhere in today’s business environment and employees expect to be able to access it regardless of where it lives. They don’t care if it’s stored in a database, retrieved from a service, found in a SharePoint list or library, or stored somewhere else up in the cloud. Regardless of where the data lives, they expect to be able to get to it on any operating system, with any browser, and using any device.

With the popularity of SharePoint across many organizations an enormous amount of business data is added into lists and libraries every day. If employees have access to SharePoint directly on their chosen device then a variety of techniques can be used to expose the data to them ranging from SharePoint pages, Web Parts, App parts, Pages, and more. However, if they won’t always be using SharePoint directly to access the data how can you get it to them? Fortunately, this isn’t a new problem and has been possible for many years using SharePoint Web Services or RESTful services. How does that process change though if you’re using Microsoft Azure, Office 365 and SharePoint?

In this article series, we’ll walk you through the process of creating an external application that can interact with Microsoft Azure Active Directory, Office 365 and SharePoint. The overall goal of the series is to show developers that may be new to SharePoint how they can leverage existing HTML and JavaScript development skills to integrate with Azure and pull Office 365/SharePoint data into custom Web applications.

This first article will discuss whether or not a SharePoint-centric application or external application should be considered. It’ll also introduce an Expense Manager application and explain what it offers. Future articles in this series will discuss the technologies used by the Expense Manager application and dive into how AngularJS can be used to build a single-page application (SPA) that can be used by employees on any device throughout an organization.

Let’s get started by discussing whether an application should be embedded directly into SharePoint or if it should be external.

Stand-alone or SharePoint hosted? That is the question!

While it’s true that SharePoint uses SQL Server under the covers, SharePoint itself is NOT a relational database. It’s ultimately up to the developer to understand how SharePoint works in order to maximize the use of the APIs and interact with the various objects and data.

Why is this important? It’s important because SharePoint is a robust platform that can be used to build a variety of applications that run inside or outside of SharePoint. With support for RESTful services, developers can leverage their existing Web development skills to enhance, expand and extend what SharePoint can do. A fundamental understanding of the building blocks of SharePoint will save a lot of time and frustration and allow developers to do what they do best while allowing SharePoint to do what it does best.

One of the key concepts you need to know about SharePoint is that you can build applications that run directly inside of it as well as applications that run outside of it. If you don’t already have data in SharePoint lists and libraries then it doesn’t make much sense to build an external application and then use SharePoint as the backend data store. In that type of scenario you’d want to use a standard database.

In situations where data already exists in SharePoint or when an organization has chosen SharePoint for you, interacting with the data through an external app that runs in browsers, on tablets, and even on phones, can make a lot of sense. That’s exactly the type of application that we’ll be discussing in this article series.

Before discussing the external application and how it accesses Office 365 and SharePoint data using RESTful services, let’s take a look at some important aspects of SharePoint so you understand the key components and how they work. If you already have experience with SharePoint you can probably skip to the next section of the article.

I’m new to SharePoint. What should I know?

Whether you’re a client-side or server-side developer, SharePoint can be intimidating at first glance so in this section we’ll take a quick look at a few key features you should know about if you’re just getting started. One of the more confusing aspects of SharePoint for those new to the product is the concept of a SharePoint Website. The home page of a SharePoint Website is delivered at something called the site level with each site being part of a collection referred to as a “site collection” (see Figure 1). Data is normally located in a SharePoint site’s lists and libraries which can be accessed programmatically.


Figure 1. SharePoint sites are organized into a site collection. Sites can have lists, libraries, and other assets in them.

While some SharePoint site files exist on the hard drive, others are located in the database. This is similar to some of the Content Management Systems (CMS) you may have used but definitely different than a “standard” website where most of the files are located on the web server’s hard drive while the data is stored away in a database.

Users and apps that use SharePoint must be authenticated via an authentication provider and then authorized at the site collection, site, list, library, folder, or item level to perform some type of action with SharePoint data. In an Office 365 SharePoint scenario, users and apps have to be authenticated and then authorized to interact with SharePoint and the items stored in it’s lists and libraries. The application discussed in this series relies on Azure Active Directory for authentication and authorization.

As a developer you can programmatically access the different objects in SharePoint lists and libraries using RESTful APIs, which is exactly what the application discussed in this article does. By consuming the RESTful APIs you can leverage your existing Web development skills and build stand-alone Web applications that look and feel exactly like you want while taking advantage of responsive design techniques so that they run (and look good) on any device.

Let’s take a look at the application that we’ll be walking you through in this article series.

Introducing the Expense Manager single-page application (SPA)

The application that will be discussed throughout this series is called “Expense Manager” and provides a way for managers to access employee expense information. Expense Manager is a prototype single-page application (SPA) built using AngularJS that relies on lists within Office 365/SharePoint that contain employee, expense, and state data. The application is available on GitHub at As mentioned earlier, authentication and authorization tasks are handled by Azure Active Directory.

If you’re new to SPAs, the term can be a bit deceiving since it sounds like there’s only one page for the entire application. A SPA consists of a single “shell” page (a page that stays visible to the user and is never reloaded) that can display different views/screens dynamically. By using SPA techniques the application can be made to feel more like a desktop application while being able to take advantage of the standard Web deployment model.

Users access the application by first logging into Azure Active Directory (AD). The application provides a login page that handles the redirect logic to the AD login as shown in Figure 2.



Figure 2. The login screen redirects users to the AD login screen.

Once the user has logged in, the application makes RESTful calls to Office 365/SharePoint to retrieve data from the lists mentioned earlier. Data returned from the service calls is bound into the user interface using AngularJS. Future articles in this series will walk through the various technologies used in the application and show how they work together.

An example of the Expense Manager home page is shown in Figure 3.


Figure 3. Expense Manager home page.

Users of the application can view employees in a card view as shown in Figure 3 or list view mode as shown in Figure 4. Both the card and list views support filtering and paging operations to make it easy to identify specific employees quickly.


Figure 4. Viewing employees using the list view mode.

The Expense Manager application also allows employee information to be edited (see Figure 5). The edit screen relies on AngularJS for client-side validation while relying on SharePoint for server-side validation. Modifications are pushed to SharePoint’s RESTful services using an AngularJS factory (more on this in a future article in the series).


Figure 5. The employee edit screen.

Finally, employee expenses can also be viewed, sorted, paged, and filtered (see Figure 6) - it’s an expense manager application after all! Individual employee expenses can also be viewed and analyzed. We’d like to add additional enhancements to this screen at some point in the future to allow for the approval or denial of expenses and will accept pull requests made through the application’s GitHub site (


Figure 6. The expenses view.

Summary and what’s next

In this first article in the series you’ve been introduced to different approaches that can be taken with SharePoint and seen how the Expense Manager app consumes SharePoint data. It’s important to consider whether an application should be hosted directly inside of SharePoint or hosted externally before development starts. A stand-alone application can be written in cases where data that lives inside of SharePoint needs to be displayed in a customized manner.

In the next article in this series, you’ll learn more about the various technologies used by the Expense Manager application and see how they work together.

Topic: Development

Sign in with

Or register

  • Your definition and our definition of "customized manner" sound like they're a bit different. We're talking about situations where you want a 100% custom app that consumes SP data. Dan Wahlin
  • Really disagree with the assertion that the need to display SP data in a "customized manner" is a strong arg for a standalone app. I suppose if you aren't customizing the SP UI otherwise at all...