This post is part of a few other posts I’ve published this week about the authentication part of working with the Office 365 APIs. Specifically, the process of authenticating and obtaining an access token that you have to include on every request to the Office 365 APIs is tricky. Maybe the base process isn’t so hard for folks, but everything around it is confusing to some. So I’m sharing stuff I’ve picked up along the way.
When calling the Office 365 APIs you have to pass along an OAuth2 access token in each request. You get this token from Azure AD by authenticating the user within the context of an app. If you’re building an application with .NET, you are likely going to use the Azure AD Authentication Library to simplify your life. Specifically, within your project you’ll likely add the NuGet package Microsoft.IdentityModel.Clients.ActiveDirectory. This contains all the stuff you’ll use to authenticate with Azure AD to obtain the access tokens. There are also ADAL NuGet packages for iOS & Android apps that take advantage of Xamarin.
So what’s all this talk about OWIN? The Open Web Internet Interface for .NET or OWIN as it’s better known, is an open & standard interface that is supposed to make the links between web servers and web applications less coupled. How does it play into the Office 365 APIs? Actually they don’t… the idea is to make the authentication process within a web application a bit simpler. Microsoft clearly wants us to use OWIN to take advantage of this architecture in our authentication in web applications and other ways that it makes sense down the road.
OK, so how do you use this? For instance, this is going to help by pushing the authentication process deeper into what we used to know as the ASP.NET pipeline. If you haven’t done this before it can be a bit confusing… but I’ve got a process that I follow that makes it easy to setup. In the next post I’ll show you how to can do this in a custom ASP.NET MVC application.comments powered by Disqus