Leveraging the Azure AD Proxy to consume on-prem APIs from an Azure Web Job using the Password Grant Type


When creating Azure AD Proxy Applications to expose on-prem WebAPIs, you have to do a few things such as:

  • Installing the proxy connector on an on-prem server (that has access to the web api)
  • Configuring KCD in order to let the service account and/or the computer create Kerberos tickets to consume the on-prem API
  • Configure your on-prem API’s IIS to work with Windows Integrated security
  • Enabling some Windows Server Features
  • Creating an Azure AD App of type “proxy” to bridge the Cloud and your on-prem API

All these steps are described on MSDN/Technet and I will not repeat them here. However, when you complete the above, you’ll notice that, unlike the other kind of apps, the Azure AD Proxy app does not permit the use of the Client Credentials Flow (app-only). This makes sense since the role of the proxy is to convert the online identity into a well known federated/synchronized user account. Therefore, the default use case when consuming an on-prem WebAPI is to involve the end user in the signin process or to reuse his identity if already logged in (from a webapp for instance). But what if you need to consume an on-prem WebAPI from a WebJob where there is no possible interaction with an end user?

With other kind of apps, you’d just use the Client Credentials Flow (app-only) but this is not available here. However, although this isn’t the same from a technical perspective, you can define an on-prem technical account (federated/synchronized) and hardcode/appSettings its credentials in the Azure Web Job (or any other component basically). Here is a piece of code showing how to get a token using OAuth2’s Password Grant Type :

static async Task<string> GetProxyHardCodedCredentials()
AuthenticationContext authenticationContext =
new AuthenticationContext("https://login.windows.net/{tenantid}/", false);

AuthenticationResult res = await
"Proxy App URL",
new UserPasswordCredential("technicalaccount@federateddomain.com", "password"));
return res.AccessToken;

With the above code, I can get a token that will allow me to interact as a technical account with my on-prem API without having to involve any actual user interaction. This is of course different from the Client Credentials Flow from a technical perspective but is quite similar from a functional perspective.

Happy Coding!


About Stephane Eyskens

Office 365, Azure PaaS and SharePoint platform expert
This entry was posted in Azure Active Directory, Azure Active Directory Proxy and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s