In this chapter, we explain how the Call Microsoft Graph or Call Own API samples can be configured to use credentials stored in the Key Vault instead of using a certificate or secret from a configuration file or a local machine certificate store.

• Acquire a certificate stored in an Azure Key Vault
• Use the certificate to acquire a token from Microsoft Identity Platform
• Use the retrieved token from the Microsoft Identity Platform to call a protected API. Either the Microsoft Graph /users endpoint to get the list of users in the Call Microsoft Graph sample or a protected API of TODO objects in the Call Own API sample.

To carry out these steps, you'd also need the following apart from the pre-requisites mentioned in the parent tutorial.

• An Azure subscription.

You'll need:

• Visual Studio and the .NET Core SDK
• An Internet connection
• A Windows machine (necessary if you want to run the app on Windows)
• An OS X machine (necessary if you want to run the app on Mac)
• A Linux machine (necessary if you want to run the app on Linux)
• a Microsoft Entra tenant. For more information on how to get a Microsoft Entra tenant, see How to get a Microsoft Entra tenant

From your shell or command line:

git clone https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2.git

or download and exact the repository .zip file.

If you want to build a sample that makes a call to the Graph API follow the setup instructions and return after you have successfully registered your application.

If you want to build a sample that makes a call to a locally running API follow the setup instructions and return after you have successfully registered your application.

In this step you'll need to create a Key Vault on your Azure tenant and then create store a certificate within that Key Vault.

You can find the instructions for creating a Key Vault here.

After the Key Vault is created upload your own certificate or create a new certificate entirely and store it in the Key Vault. To generate a certificate in the Microsoft Entra admin center select Generate as the Method of Certificate Creation instead of Import and fill in the configuration as appropriate.

If you create a new certificate you should download a CER format copy of the certificate. You'll need it to register the certificate with your application.

In the appsettings.json file contained in the daemon-console directory of either app, replace the content of ClientCredentials with the following. Replace <VaultUri> with the Vault URI value for your Key Vault and <CertificateName> with the name of the certificate stored in your Key Vault.

  "ClientCredentials": [
    {
      "SourceType": "KeyVault",
      "KeyVaultUrl": "<VaultUri>",
      "KeyVaultCertificateName": "<CertificateName>"
    }
  ]

Start the application.

If you're using Visual Studio run the app by cleaning the solution, rebuilding and then running it.

Consider taking a moment to share your experience with us.

Use Stack Overflow to get support from the community. Ask your questions on Stack Overflow first and browse existing issues to see if someone has asked your question before. Make sure that your questions or comments are tagged with [msal dotnet].

If you find a bug in the sample, please raise the issue on GitHub Issues.

If you find a bug in msal.Net, please raise the issue on MSAL.NET GitHub Issues.

To provide a recommendation, visit the following User Voice page.

If you'd like to contribute to this sample, see CONTRIBUTING.MD.

This project has adopted the Microsoft Open Source Code of Conduct. For more information, see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

Cloud applications and services use cryptographic keys and secrets to help keep information secure. Azure Key Vault safeguards these keys and secrets. When you use Key Vault, you can encrypt authentication keys, storage account keys, data encryption keys, .pfx files, and passwords by using keys that are protected by hardware security modules (HSMs).

Azure Key Vault provides a way to securely store credentials, secrets, and other keys, but your code has to authenticate to Key Vault to retrieve them. The managed identities for Azure resources feature in Microsoft Entra ID solves this problem. The feature provides Azure services with an automatically managed identity in Microsoft Entra ID. You can use the identity to authenticate to any service that supports Microsoft Entra authentication, including Key Vault, without any credentials in your code.

In a daemon application scenario, Managed Identity will work if you have it deployed it in an Azure Virtual Machine or Azure Web Job. Please, read this documentation to understand how Managed Identity works with an Azure VM.

To authenticate to Key Vault using your Azure VM, you must first grant it permissions to Key Vault using the Key Vault Access Policies. To do that, follow the steps:

1. On Microsoft Entra admin center, note the name of the Azure VM where you deployed the daemon application.
2. Enable managed identity on the virtual machine.
3. On Microsoft Entra admin center, navigate to Key Vaults and select the one that you want the daemon application's VM to access.
4. Then click on Access policies menu and click on +Add Access Policy.
5. Select an adequate template from the dropdown "Configure from template" (ie "Secret & Certificate Management") or set the permissions manually (this sample requires the permission GET for Secret and Certificate to be checked).
6. For Select principal, search for the Azure VM name or ObjectId, select it and click on Select button.
7. Click on Add.
8. Then, Save.

For more information about Key Vault, take a look at these links:

• Key Vault documentation
• Managed Identity Key Vault sample for dotnet

For more information about AzureVM and Managed Identities for Azure Resources, take a look at these links:

• Managed Identity documentation
• AzureVM documentation

For more information about the underlying protocol:

• Microsoft identity platform and the OAuth 2.0 client credentials flow

For a more complex multi-tenant Web app daemon application, see active-directory-dotnet-daemon-v2