Wednesday, 24 June 2015

AngularU Day 3

Aaron Starkston, Lead Developer, Product Development

If you haven’t been following along with our AngularU blog posts, check out Owen Craig’s Day 1 and Day 2 blog posts.

To finish up our time at AngularU, Owen Craig (@owencraig) and I (@astarkston) attended Andrew Connell’s all-day workshop for leveraging AngularJS with Microsoft technologies for the enterprise. Rich SPAs? O365? Azure? This workshop screams Rightpoint.

Andrew began the talk by touching on TypeScript before diving into O365 and the other demos. I strongly suggest reading those blog posts I linked to above if you want a deeper dive into TypeScript.

What I do want to highlight here is some of the IntelliSense you can get with TypeScript through an NPM package called TypeScript Definition (tsd), done through DefinitelyTyped. This creates a bunch of interfaces in some [language].d.ts file to get typed-IntelliSense. Once you run the tsd init command, you can generate a tsd.json file to store your tsd references as well as a tsd.d.ts to save all of your references. Once initilaized, you can run queries to search for language-specific tsd files via tsd query [library] and save these as dependencies to your local tsd.json file via tsd install [library] -s. To get this in any file, you would just need to add a reference tag to your typings/tsd.d.ts file, which was created on the initial tsd init command. If you really want to get fancy with this, you can even code a task in your build process to add this same typing IntelliSense for your own custom interfaces.

After the TypeScript plug, we got our hands dirty with a crash course on O365. We all have a rough understanding of what O365 is at its core- Exchange Online, Sharepoint Online, OneDrive for Business, etc. What’s incredibly cool is that all of these services have their own robust APIs. Apps talking to these APIs can use one of two techniques: 1) use native SDKs, like .NET or iOS; or 2) REST calls. Even better, these REST calls to O365 is that Microsoft condensed these calls down to one endpoint,, instead of requesting from different endpoints for Sharepoint Online or OneDrive for Business.

Connell went on to talk about the simplicity of Azure authentication via OAuth 2.0. The quick and dirty on this is that OAuth is an incredibly simple authentication protocol to create trust on behalf of an application’s users, i.e. the way you access an authentication token. We can use OAuth with an Implicit Flow model of authentication to achieve such authentication between our application and our remote endpoint. Please note that we used purely implicit flow authentication in our workshop; you can set this by modifying the app manifest in Azure. Azure also supports authorization code flows and client credential flows, however we're looking at implicit flows because that way we're not actulaly exposing the app secret to the end client. You can provide that remote endpoint with where you’re coming from and where you’re going. When the remote endpoint receives this request, it sends back a response with an access token and a refresh token (providing the request was valid). So once we have this access token, we just need to pass it along with every request we make and we can get our data back.

Now for the fun stuff- combining Angular + O365 development. The remaining part of the workshop walks through how to set up the connection between a SPA and O365. There are so many things you can do working with O365 development, and a lot of that can be handled with the REST API.

I’d like to highlight one key component in setting up the SPA / O365 connection: the Active Directory Authentication Library (ADAL) for Javascript. ADAL allows us to authenticate and use these tokens we receive from our first authentication request to work with O365 data across all of your Angular routes. Key point here- we keep all of this in the client! Combining ADAL with OAuth implicit flow keeps us from using any server-side authentication. Another added benefit of using ADAL is that you only have to authenticate on certain routes and it does all of this before you get to the page (super fast!), meaning that you can have this authentication on a page where you’re reading list data but don’t need to have such authentication on a static About Us page. So, for example, if in our $http.then() callback we returned this.adalService.userInfo.isAuthenticated, the result would be true. This is done in your routing engine by adding requireADLogin: true to your route config. Another beauty of the ADAL library is that we don’t even need to worry about forming our own request header…it takes care of that for us!

Now you may be wondering, "Hey Aaron, ADAL taking care of authentication for us is nice. But what happens when the access token expires?" I'm glad you asked. Remember that we get back a refresh token when we first receive our access token. ADAL use that refresh token to get a new / valid access token. The key point here is that we as developers don't have to even worry about this. It's magic (sort of)!

This was a jam-packed day of fun development. If you want to take a look at the end result of the application we worked with, pull down Andrew Connell’s git repository and take a look at the ng-ts-aad-o365 folder. Take a close look at the four TypeScript files inside the expenseApp folder. ‘app.adal.ts ‘ contains the exported Adal class (yes- class…we’re not in ES5 land anymore!), ‘app.constants.ts’ contains all the necessary components to set up the implicit flow token request, ‘app.module.ts’ contains the ADAL configuration that actually initializes that connection, and ‘app.routes.ts’ contains the requireADLogin: true I spoke of earlier to conditionally require authentication on each route.