This thread generated some ideas on how we can improve the CLI user experience for Azure authentication, which is currently used by Azure Key Vault signing. In the near future, it will also be used by Trusted Signing signing.

Background

Sign CLI's Azure Key Vault signing exposes 4 authentication-specific options. The original intent was to support 2 authentication strategies:

• tenant ID + client ID + client secret
• managed identity

Problem statement

Managed identity support is provided through Azure SDK for .NET's DefaultAzureCredential class. This class actually supports 10 authentication strategies, which are tried in a fixed order until one succeeds. In most cases, this may work like magic. However, there are several problems with this solution.

1. --azure-key-vault-managed-identity doesn't actually guarantee we'll use the managed identity authentication strategy. Authentication can fail because DefaultAzureCredential succeeded in obtaining a token with an earlier (unwanted) authentication strategy. This really happens.
2. There's no clear support for other authentication strategies (like Azure CLI). You could use the --azure-key-vault-managed-identity option, set a bunch of ExcludeXXXCredential options for all the options before Azure CLI authentication strategy, but that's a hacky, terrible user experience.
3. From a CLI UX perspective, to formally support other authentication strategies (like Azure CLI), we'd need to expose an option for it and validate the various combinations of options.

Proposed solution

First, deprecate the 4 authentication-specific options. Continue to honor the options but output a warning that users should migrate to the new solution, which is one of the following options:

• Provide no authentication-specific options. Use DefaultAzureCredential behavior.
• Use a new option (-act, --azure-credential-type) and specify the specific authentication strategy you want.

At some time in the future, remove the 4 authentication-specific options. By default, Azure Key Vault signing will require no Azure authentication options. It will support all authentication strategies provided by DefaultAzureCredential in the order that class provides.

For users who want to use a specific authentication strategy, a new option (-act, --azure-credential-type) will enable that. Note that this list of accepted values represents only a subset of strategies provided by DefaultAzureCredential on the principal that we'd add others when needed.

CC @clairernovotny, @joelverhagen, @dlemstra