Several weeks back we released some new features in developer preview mode that do an amazing job of rounding out our ISV story.
Now you can write rich client applications and secure your own RESTful web APIs using Azure Active Directory and our newly released OAuth 2.0 endpoints. You can find the announcement here.
This is big step forward for Azure AD. Most application writers these days are targeting more than web sites with browser clients. They want to write native applications for mobile devices and they might also want to write native applications for a platform like Windows 8. We now have technology in preview that uses OAuth 2.0 to let you do just that. The other thing that is exciting here is that we are continuing to deliver on the promise of Identity Management as a Service (IDMaaS) because we are one of the few service providers that lets you secure your RESTful web API for client access with an instance of Azure Active Directory that you can get from Azure, on demand, FREE! Most of the other guys let you use OAuth to get an access token to reach their set of resources (think Facebook where you use OAuth to get at Facebook resources) but they don’t give you an access token specific to securing your RESTful web APIs.
In the old days, when someone wrote an application that you installed on your mobile device or laptop they would have to ask you to enter your password into their application. They would store that password and use it to call the backend. The problem with this is that passwords stored in native clients are subject to attack, so you want to store the most scoped secret you can – for example an access token to a specific service rather than a password that can be used to get at all your data. If the application uses a central identity provider (like Azure AD) you run some risks when you give the client application a password that you use with multiple applications. And you might also want to restrict the permission the application has to act on your behalf; for example, you might be ok with it reading your information but not writing something new. If you give it your password you can’t really restrict what it does.
OAuth 2.0 provides a more scoped way to do web site to web API delegation and rich client to web API delegation. Think of it like giving a valet key to your car to someone. They can drive the car, but perhaps they can’t drive it over a certain speed and they can’t use it to open the trunk or glove box.
What we implemented was OAuth 2.0 authorization code grant. There are several profiles in OAuth. (We support the simpler client credentials profile in our GA release, where an application uses its own user ID and password to request a token to access a backend resource.) The authorization code profile is different. Azure Active Directory now provides an authorization endpoint for RESTful web APIs. The web API is registered in a particular Azure AD tenant and the native client application is also registered as able to access the web API (it is given consent to access the web API). When the user goes to use the application, a browser pops up to authenticate the user against Azure Active Directory and then redeems the login token for an authorization code from the authorization endpoint. The authorization code is passed to the application. Once it has the authorization code the application calls Azure Active Directory’s token issuance endpoint, providing the authorization code and its client ID. If these check out, the application gets a token in return that allows it to act on behalf of the user. Notice that the application never directly gets the user’s password that only is passed to the browser! The application passes this token up to the backend service (the RESTful web API) that is the other side of the application. The web API verifies the token by checking that it is a valid token issued by Azure Active Directory for authentication against this backend service.
To make all these flows easier we provide client libraries and server side frameworks to do the heavy lifting. If you are writing a .NET RESTful web API you can use our newly released JSON web token handler and Windows Identity Foundation to process the incoming token. On the client side we have provided a Windows 8 client library so you can easily handle the client side authorization flow in a modern Windows 8 application. This is in addition to wiring OAuth authorization and token issuance endpoints into Azure Active Directory. We also provide a tool called the Azure AD Graph Explorer that allows you to register your native client application and service API with Azure Active directory. This is needed because it is the way you get a client ID and secret to use with your native client application, it is the way you scope the permission that the client can have in accessing the RESTful web API service backend, and it is the way your RESTful web API service indicates that it trusts tokens from Azure Active Directory.
To help you quickly get up to speed on these new capabilities, we have built a complete step by step walkthrough that will guide you through the development and testing of a Windows Store app and a REST service. You’ll be using AAL for Windows Store to add authentication capabilities to a Windows Store app, the JSON web token handler for securing an ASP.NET Web API service, and the Graph Explorer to register the app and service. You can access it here. I really encourage you to try it out. It is very neat to see all the parts working together and it will help highlight how this can be used for your rich client applications and their RESTful web API service backends.