Office365 and AzureAD for Developers

A high level introduction to what a solution package is, and the difference between a sandbox solution and a farm solution. If you are quite familiar with SharePoint development, feel free to skip this section.

The process of writing a simple solution package, and how much of it applies to Office 365.

What are SharePoint apps, now known as SharePoint Addins?

Keeping your custom code outside of SharePoint has unique advantages, and is necessary for Office 365. Here we look at why buying into the App Model can be advantageous for you.

Apps is a big topic, but Office 365 APIs is a superior architecture. Apps will mature further, but in their current incarnation they have some serious shortcomings. Based on that, what coverage will I give to this topic, and why.

The golden rules or guiding principles of the App Model that are absolutely critical to understand.

SharePoint apps or addins can be classified in multiple ways based on different criterion. Here I talk about the different kinds of SharePoint apps.

Developing or running apps requires some unique changes to your dev environment. Here I talk about how to setup your environments to run SharePoint apps.

Time to see some code, but apps is not the focus of this course. Still it is worth mentioning for knowledge completion purposes. So what specific scenarios will I show, and how can you learn the rest.

A SHA runs entirely in SharePoint. Here I demonstrate how to write it, and how to host it. And I mention the limitations too.

An AppPart or ClientWebPart is an Iframe that pretends to be a webpart. It has some serious limitations, but solves some scenarios. Here I talk about how to write an AppPart and the various challenges it presents.

PHAs are very powerful, but also more complex to deploy. They have some unique differences between on-premises and Office365, and here I will introduce you to PHAs.

Here I demonstrate how to write a provider hosted app, and how you can deploy it on-premises and in Office 365

Why did we need Office 365 APIs and what is Microsoft Graph and why is it so important.

Azure AD is not your dad's on-premises AD. Why did we need a new concept, what does it buy us, and what is it's value?

On-Premises AD has some serious limitations, and AzureAD is quite different from it.

AzureAD is very flexible, and is designed to suit the needs of every enterprise, small, medium or large. What are those scenarios and how does it affect you the developer?

As a developer, what can you do with Azure AD?

What is ADAL, why has Microsoft created it, how can you obtain it, and why I highly recommend that you use it?

AzureAD needs to know about your app for your app to be able to make use of it. What does it mean when I say "registering your app", and what information does AzureAD need and why?

What is tenancy, why should you care, and how does AzureAD help you here?

As a developer interested in AzureAD, there are many dev. scenarios to learn. Here I describe the list of those scenarios, how they apply to Office 365, and then subsequently in rest of the course I will be covering each one of those.

Office 365 uses AzureAD, but AzureAD can be used completely independent of Office365. Here I setup the AzureAD tenancy I will be using through rest of the course, you should setup one for yourself too.

Once you have setup AzureAD, what facilities does it offer, and where can you find them?

Here we add a test non-admin user in our tenancy, which we will use at various places in the course.

PowerShell enables you to script admin AzureAD and exposes numerous facilities not visible through the UI. Here I show how you can manage AzureAD (Office 365 included) using PowerShell

AzureAD and Office365 are joined at the hip. In this course, I will demonstrate concepts using both with and without Office365. So here we learn how to access the AzureAD behind Office365.

An explanation of what I mean by Web Browser accessing web applications secured using AzureAD

Understanding all those redirects and postbacks between browser and web application and AzureAD that make all this possible.

How web applications secured by AzureAD are supposed to handle expiring sessions and tokens.

Here we dive into a demo, where I write up a simple MVC application that we will protect using AzureAD

For every scenario there are some Nuget packages we will use. Here we add the nuget packages for securing a web application

Here we use the OWIN startup.cs to bootstrap authentication in our MVC application

We add functionality to allow the user to easily sign in and out using a web browser click into our web application.

We go through the process of registering our app in AzureAD portal and what information we need to provide.

We are able to run our web application running on-premises, authenticated by AzureAD and we are able to sign in and out.

Understanding how OpenID authentication works via browser posts, and the various parameters being passed.

SPA's use a unique authentication protocol flow called OAuth2 Implicit Grant Protocol. Here we understand how that flow works, and it's unique strengths and limitations.

An introduction to the Active Directory Authentication Library for JavaScript

A deeper look into the limitations and strengths of the OAuth2 Implicit Grant Protocol.

SPAs accessing APIs protected by AzureAD do not have the luxury of using refresh tokens.What are refresh tokens? And what is a SPA supposed to do then?

How does a SPA using ADAL.js renew access tokens if it has no refresh tokens?

What differences does your application need to consider if it is a SPA accessing WebAPIs and it may need to work under either single tenant or multi tenant setups.

Here we dive into building an example demonstrating ADAL.js being used in SPAs accessing WebAPIs secured using AzureAD. The first step, is to build a sample API, without using any authentication to start with.

Nnext we use AngularJS to write up a simple application that attempts to access the WebAPI we just wrote. Remember there is no authentication involved yet.

Our SPA when trying to access the WebAPI fails because our WebAPI does not support CORS. Here we add support for CORS.

Our app should work without authentication at this point, so lets protect our WebAPI using AzureAD.

After adding AzureAD authentication support in code, lets register our WebAPI in AzureAD so AzureAD secures it.

Next we enhance our SPA to secure itself using AzureAD using ADAL.js. It's all about the access token at the end of the day.

Merely writing the code isn't enough, we also need to register it in AzureAD and enable that oAuth2 allow implicit flow thing.

The SPA won't be able to access the API unless it has permissions to do so. Here we set the permissions in AzureAD.

With our SPA registered and permissions granted, lets enhance our application to use ADAL.js to sign in/sign out and make authenticated calls.

With our application written, lets run it and examine how it works and how ADAL.js behaves at runtime.

The access token is just a JWT token. What information does it contain and how can we decrypt it? Do we need to validate it?

A behind the scenes look of how ADAL.js stores and manages sessions and access tokens etc.

What is the Microsoft Graph and what is it capable of?

We start by modifying the previous SPA we wrote in the previous section to instead target the Microsoft Graph.

We have written our SPA, but Office 365 needs to know about it, and maybe even trust it, plus there are those pesky permissions we need to worry about.

Just like our non-Office365 counterpart, we need to enable implicit flow here too.

Your app cannot call Microsoft graph unless you give it the rights to do so.

Our application running as a JavaScript SPA website successfully being able to call Microsoft Graph.

Why bother with AppParts when your pages can work as SPAs? We take the same SPA we wrote, and run it as a SharePoint page instead. Now I don't want to hear complaints about Office 365 doesn't have a good dev story.

An explanation of what exactly do I mean by "Native app" and how is that different from what we have seen so far.

Native Apps use the OAuth 2.0 authorization code grant. So naturally we need to start by introducing this important player.

How do Native apps use the OAuth2.0 authorization code grant, and how is it uniquely different from JavaScript SPAs

Native app specific considerations when it comes to tenancy.

Lets start writing the native app talking to the web api, but we are going to need an Azure protected web api first. Lets get that out of the way first. This is shockingly simple as you'll see.

Next we add a native app into the project and set it's overall structure up. No authentication or AzureAD tie up yet.

Here we add some nuget packages that make it possible for our native WPF app to work with AzureAD

We also need some framework libraries to make https calls from a WPF app, so lets add references for those.

We reference the basic details we are going to get from AzureAD in our Native app

We are not using a browser, or are we? Why are redirect URIs important for native apps, and unique considerations for windows store apps.

Native Apps are unique that they are able to manage long term tokens (refresh tokens) securely using encrypted storage. What hooks does ADAL provide to allow us to manage tokens?

How do we make a sign in request, and how do we ensure that a signout is a full and secure signout?

After a successfull sign in, how do we get a hold of the access token, and how can we make an authenticated call to the service.

Demonstration of the application running with the sign in/sign out and authenticated call in action

An explanation of what we are about to build here.

Hunting for interesting APIs and registering apps on dev.office.com. We look for the mail api.

For those not familiar with AzureAD, you can register various apps right on dev.office.com

Registering your native app in the AzureAD of Office365

Here we grant permissions to our app to read our mails, and run the app first without permissions, and second with permissions.