Azure Key Vault logo

How to authenticate against Azure Key Vault both in Azure and local development environment?

This post was most recently updated on February 10th, 2022.

2 min read.

Azure Key Vault is great. But when developing locally, it can be a bit of a pain. You can always circumvent it and create some classical solution, such as simply wrapping all of your key/secret assignments in if-else-clauses that will use local configuration if you’re running locally and only call the Azure Key Vault if you’re in the cloud… But that feels so incredibly early-2000-ish. Isn’t there a better option available?

I mean – obviously, there is! And we’ll see how it works in just a while :)


Azure Key Vault configuration is incredibly simple if you use Managed Identities – but they’re not available when you’re just debugging your code locally. Using different sources for your keys/secrets is definitely possible, but it adds a bit of complexity to your code and is bothersome to maintain.

If only there was a great way to securely and automatically connect to the Azure Key Vault from both Azure and my local development environment…


In comes the AzureServiceToken! It uses the Managed Identity if one is available – but will fall back to another method in the following order:

  1. A managed identity for Azure resources
  2. Visual Studio authentication
  3. Azure CLI authentication
  4. Integrated Windows authentication

With that out of the way, see the steps below:

Time needed: 15 minutes

How to implement Azure Key Vault for local development & Managed Identity?

  1. Add your dependencies

    Add these NuGet packages:

    Versions (for me, anyway) were 1.6.2 and 2.1.1, respectively. These should work for at least .NET Core 3.1 (and probably newer).

  2. Implement authentication

    Something like this should work:

    // This works in DEV environments (as long as you've run "az login" first) and in Azure as long as Managed Identity has been configured
    var azureServiceTokenProvider = new AzureServiceTokenProvider();
    var keyVaultClient = new KeyVaultClient(new KeyVaultClient.AuthenticationCallback(azureServiceTokenProvider.KeyVaultTokenCallback));

    And the using-statements should be somewhat like this:

    using Microsoft.Azure.KeyVault;
    using Microsoft.Azure.Services.AppAuthentication;

    And after this, something like this should work:
    var secretBundle = await keyVaultClient.GetSecretAsync($"{Environment.GetEnvironmentVariable("KeyVaultName")}/secrets/{keyName}").ConfigureAwait(false);
    var secret = secretBundle.Value;

  3. (OPTION 1) Sign in to Visual Studio using the credentials that can access the Key Vault

    In case you CAN log in to Visual Studio with just the account that is able to connect to Azure Key Vault, that’s probably the easiest thing to do. That (cached) identity should be used as-is by the Azure Key Vault client.

    However, if you need to use multiple accounts in your Visual Studio, this won’t work. Well, in my experience, usually it won’t.

    But no worries, as there’s another way to populate the credential cache…

  4. (OPTION 2) Use az CLI to store your preferred account into the credential cache

    This is only required if your preferred credential is not your main Visual Studio account.

    To perform this step, you’ll need the az CLI – which you can download from here:

    Then, open a command line and run “az login” with your user.

And you should be good! Yeah – it is pretty much magic. But with modern computing, what isn’t?


5 4 votes
Article Rating
Notify of

most voted
newest oldest
Inline Feedbacks
View all comments