Write rich clients and secure *your* RESTful web APIs with Azure AD

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.


New, Better User Experience, and a new Icon

Azure Active Directory went GA last week, but something that happened the week before that was also pretty exciting.  We updated the look and feel of the authentication experience of Azure AD.

Lots of people using Office 365 couldn’t help but notice, but I’d expect that many of them didn’t realize they were actually using Azure Active Directory.  There was a nice press write up on the new user experience at this link: http://winsupersite.com/office-365/office-365-upgrade-new-sign-experience

In particular we changed three things:

  1. We tailored the experience to whatever device you use for accessing the login page.  It now auto-resizes and formats for mobile, tablet or web browser.
  2. We store a tile that remembers your login.  This makes it super easy to login again after your first login, especially if more than one person shares a machine.
  3. We introduced an icon that will represent your account in Azure Active Directory.

We are still playing around with the text but the thing that really sticks out is the icon.  This is an image of it:


What we are trying to say is that this account is about work – be that work at a company, business, school, government, or other organization - and that this account is owned and managed by your company.  Not Google, Facebook, Microsoft or anyone else!  We (Microsoft) are simply the service provider for your infrastructure.  We help you run it, but you own it, not us.

So when you go around the web, expect to see this icon popping up more and more.  And if you are building an app you can check out our branding guidance for using this icon at this link.  Now that Azure Active Directory has gone GA as a platform for 3rd party applications (see my last post), expect to see it even more because it will be the way you log in to our business services, other applications that extend our business services, or applications that trust Azure Active Directory for sign in.


Azure AD General Availability

Exciting news this week!  Azure Active Directory came out of preview and into general availability on Monday. The blog post announcing this can be found at http://aka.ms/y4b3yc.

One thing to realize is that Azure Active Directory has been supporting all of the user base of Office 365 (millions of customers) for several years already, so in some sense a large part of it was already generally available as supporting infrastructure for Office.  What is new in this announcement is that we are now supporting line of business and 3rd party applications with Azure Active Directory.  Customers can write their own applications and have them trust Azure AD for sign in and their applications can access information contained in the directory.   Independent software vendors can also write applications, register them in the directory, and any customer subscribed to Office 365 can sign up for them.

To make this even cooler, if someone has an Azure subscription that they use for developing software they can get Azure Active Directory as a service for them to use as well (in similar fashion to getting a web site or a SQL server.)   Once you have an Azure AD tenant in your subscription you can use it for registering your application to offer it to the entire user base of Office 365.

So I encourage you to try it out. There are three great walkthroughs online that our team has created.  The first one shows you how to create a simple line of business application.  The second one shows how to have your application access information in the directory.  The third one shows how to take that application and make it available as a 3rd party application for other Azure Active Directory users (which means everyone that has Office 365) to subscribe to.  The documents for these walkthroughs can be found at:  http://www.windowsazure.com/en-us/manage/services/identity/ under the “build” section.  If you want to read more, our MSDN library for developers is here:  http://go.microsoft.com/fwlink/p/?linkid=290966&clcid=0×409 and our TechNet library for IT pros is here:  http://go.microsoft.com/fwlink/p/?linkid=290967&clcid=0×409.

If you have any questions post them here and I’ll try to answer them.



Hi Folks,

This is a blog and web site that is dedicated to getting the word out about Azure Active Directory (and on the side sharing some thoughts about the process of building software products at Microsoft and managing teams).   I’ll be updating you with news on what we are releasing, interesting customer scenarios we are hearing about, and things you can do with our software.   Hope you find it interesting!  I’m also looking forward to hearing from you and hearing about where you would like our products to go.

David Howell, Group Program Manager, Microsoft

Azure Active Directory