[Feature Request] Support for KeyVault sign when using ClientCredentials

Is your feature request related to a problem? Please describe. All samples related to Client Credentials suggest to put a certificate in the Key Vault, registering that certificate in the application and accessing the certificate using a managed identity. Which is all great, but I think no one is aware that the certificate might be exported either by a hack changing the application code or by getting in from memory.

Not even talking about what would happen if a malicious developer would extract the certificate.

All samples show something like:

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

public async Task<string> GetToken(...)
{
  const string ceyVaultUri = "https://{kv-domain}.vault.azure.net/";
  const string certName = "{some-certificate-name}";
  var tokenCredential = new DefaultAzureCredential();
  var secretClient = new SecretClient(new Uri(keyVaultUri), tokenCredential);
  var secretResult = await secretClient.GetSecretAsync(certName).ExecuteAsync();
  // Certificate is now present on client machine
  var certificate = new X509Certificate2(Convert.FromBase64String(secretResult.Value.Value));

  const string clientId = "d294e746-425b-44fa-896c-dacf2c7938b8";
  const string tenantId = "42a26c5d-b8ed-4f1b-8760-655f98154373";

  var app = ConfidentialClientApplicationBuilder
    .Create(clientId)
    .WithAuthority(AzureCloudInstance.AzurePublic, tenantId)
    .WithCertificate(certificate)
    .Build();

  var tokenResult = await app
    .AcquireTokenForClient(new[] { "https://graph.microsoft.com/.default" })
    .ExecuteAsync();

  return tokenResult.AccessToken;
}

Describe the solution you’d like

I would like to see a warning in the documentation about the possibility that people can extract the certificate and possibly gain persistent access to customer data. The solution is in the KeyVault, instead of downloading the certificate and signing the client assertion on the application side, you can also use the Key Vault to sign the unsigned assertion in the cloud, mitigating the possibility to extract the data.

I created a poc to do exactly that and I could use some assistance in getting this in MSAL.net if you’re open to that.

// Seeing support for 'WithKeyVaultKey' instead of 'WithCertificate' is the main goal here
IConfidentialClientApplication app = ConfidentialClientApplicationBuilder
  .Create(clientId)
  .WithAuthority(AzureCloudInstance.AzurePublic, tenantId)
  //.WithCertificate(certificate)
  .WithKeyVaultKey(keyId, hash, cred)
  //.WithRedirectUri(redirectUri )
  .Build();

Describe alternatives you’ve considered Making people aware of the possibility of certificate extraction is the first part that can be tackled.

Additional context

• Blog about the issue
• Blog about solution
• Demo on 425 show

[bgavrilMS]

@jmprieur @jennyf19 - we’ve had a few people over the years discussing this. Wouldn’t it fit into Microsoft.Identity.Web.Certificate ?

[svrooij]

@bgavrilMS It’s exactly doing what I’m trying to avoid (and everybody else should as well). It’s is downloading the certificate from the key vault and using it to sign the client assertion on the client side (while thus making the certificate exportable, by this app or a malicious (or hacked) admin/developer).

I tried to explain the differences between the two options in this post