So, back in the day we used x509 Certificates to authenticate to Azure’s API. A year or so ago, Azure Active Directory became the defacto method of authentication. MSDN talks about it in the article: Authenticating Azure Resource Manager requests. From the article:
“All of the tasks that you do on resources using the Azure Resource Manager must be authenticated with Azure Active Directory. The easiest way to do this is to use PowerShell or Azure CLI. If you don’t have access to PowerShell or Azure CLI, use the Azure Management Portal to set up authentication.“
So yea… this isn’t necessarily true. I worked with a couple of folks from support engineering to use the common authentication endpoint, so that you don’t have to setup an application in Azure Active Directory and provide an application id.
I posted the code up to GitHub here: devdash/EzAzureMgmtApiAuth.
*Note: I can’t claim this is supported in anyway… but it works great and has since the beginning.
Basically it’s a console app that asks you to login using your Azure credentials, asks you which subscription you’d like to use if you have more than one, and then finally prints out the choice you made. Simple, but I think powerful.
If you’re anything like me, you’ll open Git Shell and run:
git clone https://github.com/devdash/EzAzureMgmtApiAuth.git
Then open the SLN:
C:\src\gh\EzAzureMgmtApiAuth [master]> .\AzureRestPlayground.sln
Now normally once I have the solution open in Visual Studio and I see that it’s a console app I start looking at: Program.cs. Below is the relevant code, the code that kicks off the authentication process…
static void Main(string args)
var azSubs = new AzureSubscriptions();
var subList = azSubs.GetSubscriptionList();
This code isn’t rocket science. It initializes an object of type AzureSubscriptions and calls the method GetSubscriptionList. Let’s go have a look at this method, particularly the second line:
string token = AuthHelper.GetAuthorizationHeader();
Off to look at the AuthHelper class and it’s static method GetAuthorizationHeader…
public static string GetAuthorizationHeader()
AuthenticationResult result = null;
var context = new AuthenticationContext("https://login.windows.net/common"); // tenant agnostic endpooint
result = context.AcquireToken("https://management.core.windows.net/",
"1950a258-227b-4e31-a9cf-717495945fc2", // Windows Azure Management API's Client ID
new Uri("urn:ietf:wg:oauth:2.0:oob")); // standard redirect for native apps (console, desktop, mobile, etc)
if (result == null)
throw new InvalidOperationException("Failed to obtain the JWT token");
And here finally we se some good stuff. We got all this good ness by pulling in the ADAL nuget package and writing a couple of lines of code. We pulled the “Client ID” being passed to the AcquireToken method using fiddler and tracing a “promoted” app and borrowing it’s ID. This is why my note above states that this probably isn’t supported. From here we are returned a token. We construct our Auth Header in the HttpHelper class using this line of code:
request.Headers.Add(HttpRequestHeader.Authorization, "Bearer " + token);
Well that’s that. Using the ADAL library and a common auth endpoint. Now any app can authenticate to any subscriptions service management API given the right credentials. Awesome!!