There are certain application workloads which run in Azure hosts for which the DefaultAzureCredential is not well suited. Particularly applications which call into Microsoft Graph APIs can find the DefaultAzureCredential to be problematic due to its use of a first party app id for development time credentials, such as the VisualStudioCredential, VisualStudioCodeCredential, AzureCliCredential and AzurePowerShellCredential. Tokens acquired by a first party app don't have a consent experience, often are more permissive than desired, and are specifically not supported by some APIs. Because of these limitations, applications such as these need to create an AAD application up front so that they can be prescriptive about what permissions are needed and, in the case that they need to authenticate users, provide the proper consent experience.
We want to provide these applications an experience similar to the DefaultAzureCredential where they can transition between the development environment and the deployed Azure host managed identity environment, without having to have additional configuration or change their code. To accomplish this we propose adding a new credential the AzureApplicationCredential which will provide a built in credential chain similar to the DefaultAzureCredential, but be limited to only authenticating via a service principal or managed identity.
Initially the AzureApplicationCredential would essentially be the first 2 credentials of the DefaultAzureCredential chain.
EnvironmnetCredential > ManagedIdentityCredential
This will allow users to provide service principal credentials through the environment when executing locally, and a managed identity when deployed to the azure host.
OPEN QUESTION: Should the
AzureApplicationCredentialallow users to specify service principal credential details through code? This would be different from theDefaultAzureCredentialwhere users can only provide service principal credential information via environment variables. However, since this new credential strictly authenticates applications perhaps also providing a means to configure via code makes sense.
If we want to make the AzureApplicationCredential day zero experience as simple as the DefaultAzureCredential we need to improve the tooling we have for provisioning apps, and managed identities in azure. The tooling should guide users through provisioning their application and managed identities so they can quickly create an application with the necessary permissions without having to fully understand all the detail of service principal authentication, scopes, consenting, and RBAC before getting started. The user should be able to learn about these topics progressively as they develop their application.
Whatever app provisioning tooling we guide users to should also be available to developers in all our core languages to provide a consistent experience. To start we would most likely provide guidance to provision the application via the Azure CLI since this is something Azure developers will commonly use, but the experience here is not as guided as we would like. The AAD DevEx team is investigating how to best improve the tooling in this area, and we should work with them to keep our guidance up to date with their recommendations.
Because the AzureApplicationCredential will require up front setup, we should provide guidance in our error messaging in the case the environment is not fully configured, or the app is not authorized to acquire tokens for the necessary scopes. Our error message should link to documentation on how to setup the application prior to using the AzureApplicationCredential.
Investigation is needed to determine how we can identify errors from the STS which indicate the application is not properly configured, or doesn't have the appropriate permissions so our error messages can provide actionable guidance.
Footnote: This design proposal is an iteration of a previous proposal reviewed by the Arch Board, the details of which can be found in this issue.