In the third post in my series about secure authentication to Azure services, we will explore how we can access Azure resources from servers hosted on-premises or in other clouds without storing any kind of credentials, like client secrets or certificates, on them.

For the previous posts in this series, please check the following articles:

A secure password is the one you don’t know

As I mentioned in my first post, I encourage people to use managed identities to authenticate to Azure services whenever possible. The use of managed identities greatly simplifies the management of communication credentials in your application. Plus, it helps you mitigate many security risks related to storing and using the app’s secrets, passwords, keys, etc. You no longer need to worry about leaked passwords, rotating your credentials, or ensuring that different environments use different credentials.

When hosting your applications in Azure, managed identities should be your number one choice for most authentication scenarios between application components. However, what do you do in more common hybrid or multi-cloud setups when your application infrastructure is partially located outside of Azure?

In that case, you can extend the identity functionality of Microsoft Entra ID beyond Azure using Azure Arc and do it for free.

Azure Arc provides many more useful features other than utilizing managed identities, but they are not the focus of this article.

Technically, after you install the Azure Connected Machine agent on your non-Azure server, it will link the server with the connected machine’s Azure identity and create a local identity endpoint that can be used to request an access token for your application.

How to use managed identity on Azure Arc-enabled servers

As I explained in my post about using certificate credentials to authenticate to Azure services, you can configure your application to use specific identity types in a few ways.

The first and most preferable option is to rely on the built-in fallback mechanism of the DefaultAzureCredential class. If you don’t set the environment variables, it will try to authenticate with a managed identity as the third option in the sequence. In practice, that means you don’t need to change anything in your code, and the same code that worked with authentication using client secret or client certificate will continue to work provided that you configured the required permissions for the managed identity to access the target Azure resource 👇:

Note. The account used to run your application must be a member of a specific group on an Azure Arc-enabled server to access the identity endpoint and get access tokens. Otherwise, you might get an error like the following:
Authentication Failed. ManagedIdentityCredential authentication failed: Access to the path 'C:\ProgramData\AzureConnectedMachineAgent\Tokens\292daa9f-1794-43f4-a246-6f6cc6ca4e03.key' is denied.
Also, if you run your application interactively, you need to do it with elevated permissions as administrator.

The second option is to use application settings like configuration in .NET to explicitly tell your application to use a managed identity to connect to an Azure service. For example, the code below is the same that I used to connect from the sample .NET Worker service using certificate credentials configured in an appsettings.json file 👇:

Now, you can tell the app to specifically use the managed identity without changing your application code:

As you can see, compared to using certificate-based authentication to Azure services, you no longer need to worry about configuring, securing and rotating connection credentials with managed identities. All of it is done for you. You can focus more on your application functionality rather than on non-customer-facing tasks. Moreover, you can easily switch between different authentication methods by following the recommended approaches to using Azure Identity libraries in your application.

You can also check the sample code in my GitHub repository: azure.authentication-samples.

Have you tried to use managed identities on Azure Arc-enabled servers? What was your experience with it? Share your thoughts in the comments below 👇