ADAL v2 and Windows Integrated Authentication

The release candidate of ADAL v2 introduces a new, more straightforward way of leveraging Windows Integrated Authentication (WIA) for your AAD federated tenants in your Windows Store and .NET applications.

Its use is very simple. You might have read here that we model direct username/password authentication by holding those credentials in one instance of a new class, UserCredential. To take advantage of WIA you use the exact same principle: you create one empty instance of UserCredential and pass it through, that will be your way of letting ADAL know that you want to use WIA. In practice:

AuthenticationResult result = 
     authContext.AcquireToken(todoListResourceId, clientId, new UserCredential());

If you are operating from a domain joined machine, you are connected to the domain network, you are signed in as a domain user, and the tenant used in authContext is a federated tenant, you’ll get back a token right away!
Once you successfully get a token that way, ADAL will create a cache entry for it as usual; from that moment on, it won’t matter how the token was acquired – it will be handled as usual and available for lookup from any other AcquireToken overload.

Things to note:

• Some setups will make it hard for ADAL to discover the setup (domain, etc) from the currently signed in user. In those cases, you can create a UserCredential with just the user’s UPN – that will skip the local discovery phase.
• In Windows Store apps you need to opt in for the enterprise authentication capabilities: that means that in your app manifest you need to add the capabilities for enterprise authentication, intranet and shared certificates. In ADAL, you need to set to true the property UseCorporateNetwork on the AuthenticationContext you’ll use for acquiring your token.
• This functionality is predicated on your setup being an exact match to the canonical AAD federated tenant topology. If you have more than one ADFS in the chain, or if you have an IdP which does not expose endpoints behaving exactly as ADFS, this flow won’t work.

Although it was already possible to take advantage of WIA with the older OM (by using promptbehavior.never against a federated tenant) we are confident that this simpler and more predictable mechanism is more in line with the convenience it is legitimate to expect when operating within a domain. Enjoy!