This might be the most requested feature for ADAL: the ability of authenticating a user by pumping in username\/password, without showing any pop up. There are perfectly legitimate scenarios that require that feature; unfortunately there are also many ways in which abusing this feature might backfire.<\/p>\n
With the RC we just released, we added this feature to ADAL .NET (but not to Windows Store or Windows Phone). We have a sample showing how to use it; here I\u2019ll highlight the minimal syntax that lights it up, discuss some considerations about different cases,\u00a0 and above all I\u2019ll spell out limitations and warnings about what you are bargaining when you choose to go this route.<\/p>\n
There are a number of scenarios where the direct use of username and password is inevitable. The ones below are the ones I encountered most often.<\/p>\n
Note that all of those scenarios could be potentially solved by Windows Integrated Auth (WIA), however not all setups can leverage that (e.g. cloud-only tenants, clients running outside of the domain, etc) hence in the below I assume we\u2019re in such unfortunate cases.<\/p>\n
Say that you are operating from a console app, running on a Server Core. There is simply no Windows manager on the box to render any UX \u2013 everything needs to take place in text.<\/p>\n
During the Ask the Expert night at this year\u2019s TechEd North America I met with a gentleman who described a setup in which he was using legacy hardware already sending username and password. His investment in such clients was massive and decomissioning them (or the software running on them) was out of question. He very much wanted to move to AAD and move his backend to the cloud, but could not rely on our current credential gathering experience. The direct use of username and password will allow him to bridge his legacy solution to his new cloud based backend, secured via AAD.<\/p>\n
This is an all-time favorite of our partners within Microsoft. If I\u2019s have a dollar for every mail\/IM\/hallway conversation I got about this\u2026 ![\"Smile\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2014\/07\/wlEmoticon-smile1.png\")
\nThe scenario is simple: you have a solution based on native clients and you want to automate its verification. Existing test harnesses don\u2019t always make it easy to automate a web based credential gathering interface, hence the request for a mechanism to easily obtain tokens in exchange for test credentials.<\/p>\n
This is easy: in pretty much any other case! Direct manipulation of credentials is a BIG responsibility that significantly grows your attack surface, is conducive of bad habits (like caching the credentials), denies you pretty much all of the advantages you get by presenting a server-driven experience (multi factor auth, consent, multi-hop federation, etc \u2013 see below) and makes your client deployments brittle.<\/p>\n
The main anti-pattern hidden behind requests for this feature is the desire for customizing the authentication experience. I totally understand that desire, but I often get the impression that the tradeoff one makes when going that route are not always well understood. Falling back to direct credential manipulation is an awfully high price to pay: it cuts you our from a long list of features and puts both your users and your app at risk. I would rather hear your feedback about what parts of the server-provided UX you want to customize – and fiercely fight for you in shiproom to make that change happen \u2013 rather than helping you through a security crisis.<\/p>\n
Enough with the doom & gloom, let\u2019s take a look at some code! I\u2019d daresay that the way in which this feature has been implemented fits right in in the existing, well-proven credentials model we introduced since v1 for handling client credentials flow (see this sample<\/a>). Where user is a string containing the UPN of the user you want to authenticate, and password is a string or a SecureString containing\u2026 well, you know.<\/p>\n How to you use uc for getting a token? Well, we added a couple of overloads to the AcquireToken* family:<\/p>\n <\/p>\n The relationship between the client app and the resource is precisely the same one you learned about in all other single tenant native client->web service ADAL samples: both need to be registered, the API needs to expose at least a permission, the client needs to be configured to request such permission, and so on. Note that ehre there is no opportunity for AAD to prompt for consent, hence flows which would require it are off limits here.<\/p>\n Once you call one of those overloads, as long as you provided the correct credentials (and your tenant is configured correctly) you\u2019ll get back a standard AuthenticationResult, the resulting tokens will be automatically cached, and so on.<\/p>\n You can get a feeling of how this all works by giving a spin to our headless native client sample on GitHub.<\/a> Here there\u2019s a screenshot of a typical run, to give you a feeling of the experience you can achieve with this flow. Party like it\u2019s \u201895! ![\"Winking](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2014\/07\/wlEmoticon-winkingsmile.png\")
\nFor the visitors form the future: this feature lights up for the first time in ADAL version 2.7.10707.1513-rc<\/a>.<\/p>\n
\nWe introduced a new type, UserCredential<\/strong>, which represents a user credential. If you want to use username and password, you\u2019d initialize a new instance via the following:<\/p>\nUserCredential uc = new<\/span> UserCredential(user, password);<\/pre>\n<\/pre>\n
public<\/span> AuthenticationResult AcquireToken(string<\/span> resource, string<\/span> clientId, UserCredential userCredential);\r\npublic<\/span> Task<AuthenticationResult> AcquireTokenAsync(string<\/span> resource, string<\/span> clientId, UserCredential userCredential);<\/pre>\n<\/p>\n
![\"image\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2014\/07\/image_thumb2.png\" "\\"image\\"")
<\/a><\/p>\n