How to validate user credentials in Azure AD with Web application / WebAPI

Question

I have a web application. In the home page, user will enter the credentials, and system should validate against Azure AD and proceed further.

When I use a native app, and use UserCredentials , it validates the user, but if I use same approach for WebAPI, it throw the exception

The request body must contain the following parameter: 'client_secret or client_assertion'

When I use the WebAPI using clientCredentials , it generates the accessToken, which do not validate the user credentials. I also tried passing the credentials as part of httpclient headers in the consequent calls, it is working despite the wrong credentials.

string AzureADSTSURL = "https://login.windows.net/{0}/oauth2/token?api-version=1.0";
string GraphPrincipalId = "https://graph.windows.net";

string userid = "userid";
string password = "pass";

string tenantId = "axxx";   //  webapi
string clientId = "bxxx";
string clientSecret = "cxxx";
string authString = String.Format(AzureADSTSURL, tenantId);

var context = new AuthenticationContext(authString);

UserCredential userCredentials = new UserCredential(userid, password);
AuthenticationResult authenticationResult = context.AcquireToken(GraphPrincipalId.ToString(), clientId, userCredentials); // this works only if the clientId corresponds to a native app

ClientCredential clientCredential = new ClientCredential(clientId, clientSecret);
AuthenticationResult result = context.AcquireToken(GraphPrincipalId, clientCredential);


HttpClient httpClient = new HttpClient();
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(result.AccessToken, Convert.ToBase64String(UTF8Encoding.UTF8.GetBytes(userid + ':' + password)));

httpClient.GetAsync("http://localhost:11455/Login.aspx");

Is there a way to validate the credentials without using native app? Graph API is not a right choice for this I believe.

Answer 1

I was trying to do the same thing, and ran into the same error:

The request body must contain the following parameter: 'client_secret or client_assertion'

I banged my head on it for a while, and then hit up AzureSupport on twitter.

Turns out this type of auth is only supported if you set up the Azure AD App as Native Client Application . If you set it up as a Web Application then you get that error because the only way to access a web application in Azure AD is via client ID + secret.

You can have multiple apps on top of a single AD, so you can just set up a second app as native client to authenticate the same users in that directory.

Answer 2

You can certainly use WebAPI. Here's how to set it up:

If you use Azure Web Apps, which supports ASP.NET MVC then you can use the Azure Active Directory authentication mechanism. Here is a blog post describing how to set it up: https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-how-to-configure-active-directory-authentication/

Once you have that, auth will be enabled for your app and you can configure the AAD app in the portal. See this blog post for more details: http://blogs.technet.com/b/ad/archive/2014/12/18/azure-active-directory-now-with-group-claims-and-application-roles.aspx

Here is an example which shows how to read AAD group claims from a web app: https://github.com/Azure-Samples/active-directory-dotnet-webapp-groupclaims

Once you have the tokens, you can then call a Web API, which is shown by this example: https://github.com/Azure-Samples/active-directory-dotnet-webapp-webapi-openidconnect

There's a good list of AAD examples here: https://azure.microsoft.com/en-us/documentation/articles/active-directory-authentication-scenarios/

Answer 3

Short answer: No

I would consider this article to be the authoritive answer as to why.

No web sites/confidential clients
This is not an ADAL limitation, but an AAD setting. You can only use those flows from a native client. A confidential client, such as a web site, cannot use direct user credentials.

Direct use of username an password is [...] a bit of a Faustian pact – the price you pay for its directness is in the many limitations it entails and the reduced flexibility that it imposes on any solution relying on it.