![\"Smile\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2013\/10\/wlEmoticon-smile6.png\")
let\u2019s take a step back:<\/p>\nWe are going to publish a sample doing justice to this scenario soon, but in the meanwhile I am getting questions about this multiple times per day hence I think it\u2019s time to whip up a super-quick post and unblock some of you guys.<\/p>\n
Wait, what am I talking about? Perhaps I rushed a bit into it let\u2019s take a step back:<\/p>\n
Say that you have a Web application. Say that as part of the functions it perform, your app needs to call a Web API. Say that such Web API is protected by a Windows Azure AD tenant. How do you obtain a token for it?<\/em><\/p>\n The answer is \u2013 via OAuth2, of course; and via ADAL, if you don\u2019t want to write too much code.<\/p>\n You might have already seen how to use ADAL for obtaining tokens from native applications: the flow for Web applications is a little different. If you want to follow along, this would be a good time to drop in VS2013 and create a new Single Organization \u2013 cloud MVC app. Make sure you choose read or write in the bottom dropdown.<\/p>\n If the differences with the native client case would end here, things would be pretty easy; we\u2019d just add to AcquireToken a parameter for passing the client secret and we\u2019d be done. However differences do run a bit a deeper here. Despite the simplifications afforded by the above, the OAuth2 code grant still requires us to ship the user offsite to obtain an authorization code, retrieve that code once it comes back and use it to call AAD and obtain the necessary token(s).<\/p>\n That flow is heavily dependent on the stack you are using for developing your web app, hence it was not possible for us to wrap it in its entirety in a single call as we\u2019ve done for the native clients. Rather, in ADAL this flow is split in two phases:<\/p>\n #1 is the part that is dependent on the development stack, hence it\u2019s up to you to implement it in whatever way is appropriate for the tech you used. #2 is all automated goodness.<\/p>\n So let\u2019s make that happen, shall we?
Web apps are characterized in the OAuth2 spec as \u201cconfidential clients\u201d, that is to say clients that can keep a secret: the idea is that what you save on your web server is not accessible to anybody else, hence you can safely save keys there. As such, during the token acquisition flow your app is required to use such a secret to identify itself. In practical terms, this means that when you create your app in the directory tenant you need to have a credential of some sort (a secret, a certificate, etc) assigned to it and later use it from your code. The good news? When you create one Web app with the new VS2013 ASP.NET templates, and you assign read or write directory access rights to it, the creation process itself will provision a secret for your app and will even make you the courtesy of saving it in your web.config, ready for you to use! That secret is put there so that your app can call the Graph API (through another flow, the client credential grant, but that\u2019s a story for another day) but it will just as well for our scenario.<\/p>\n![\"image\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2013\/10\/image38.png\" "\\"image\\"")
<\/a><\/p>\n
In a native client the main app UI activity is well separated from the token acquisition flow, which takes place in a dedicated browser dialog; but for a Web app all the action takes place entirely in the browser! That means that if the user needs to interact with some external UI in order to grant to the Web app access to the Web API, he\/she needs to be shipped out to the authority that renders the consent UI and come back with some artifact showing that consent has indeed been granted. Now, the example I am showing is super special and no UI needs to be actually shown \u2013 for 2 reasons:<\/p>\n\n
I am doing this simplified scenario because it\u2019s already 11:40PM and I can\u2019t write this post all night, but in fact it\u2019s perfectly possible for you to use a different tenant or even implement web sign on in completely different fashion, without even using Windows Azure AD. There would simply be more provisioning steps involved.<\/li>\n<\/ul>\n\n
You are also responsible to set up a handler\/page\/action at the configured return URL to retrieve the authorization code<\/li>\n
Navigate to your Windows Azure portal, select the app you create via VS, and click Configure. You\u2019ll get to the screen below.<\/p>\n