How to authenticate Python apps to Azure services using the Azure SDK for Python
When an application needs to access an Azure resource such as storage, key vault, or cognitive services, the application must be authenticated to Azure. This is true for all applications, whether deployed to Azure, deployed on-premises, or under development on a local developer workstation. This article describes the recommended approaches to authenticate an app to Azure when using the Azure SDK for Python.
Recommended app authentication approach
It is recommended that apps use token-based authentication rather than connection strings when authenticating to Azure resources. The Azure SDK for Python provides classes that support token-based authentication and allow apps to seamlessly authenticate to Azure resources whether the app is in local development, deployed to Azure, or deployed to an on-premises server.
The specific type of token-based authentication an app should use to authenticate to Azure resources depends on where the app is being run and is shown in the following diagram.
- When a developer is running an app during local development - The app can authenticate to Azure using either an application service principal for local development or by using the developer's Azure credentials. Each of these options is discussed in more detail in the section authentication during local development.
- When an app is hosted on Azure - The app should authenticate to Azure resources using a managed identity. This option is discussed in more detail below in the section authentication in server environments.
- When an app is hosted and deployed on-premises - The app should authenticate to Azure resources using an application service principal. This option is discussed in more detail below in the section authentication in server environments.
The DefaultAzureCredential class provided by the Azure SDK allows apps to use different authentication methods depending on the environment they're run in. This allows apps to be promoted from local development to test environments to production without code changes. You configure the appropriate authentication method for each environment and
DefaultAzureCredential will automatically detect and use that authentication method. The use of
DefaultAzureCredential should be preferred over manually coding conditional logic or feature flags to use different authentication methods in different environments.
Details about using the DefaultAzureCredential class are covered later in this article in the section Use DefaultAzureCredential in an application.
Advantages of token-based authentication
Token-based authentication is strongly recommended over using connection strings when building apps for Azure. Token-based authentication offers the following advantages over authenticating with connection strings.
- The token-based authentication methods described below allows you to establish the specific permissions needed by the app on the Azure resource. This follows the principle of least privilege. In contrast, a connection string grants full rights to the Azure resource.
- Whereas anyone or any app with a connection string can connect to an Azure resource, token-based authentication methods scope access to the resource to only the app(s) intended to access the resource.
- In the case of a managed identity, there is no application secret to store. This makes the app more secure because there's no connection string or application secret than can be compromised.
- The azure.identity package in the Azure SDK manages tokens for you behind the scenes. This makes using token based authentication as easy to use as a connection string.
Use of connection strings should be limited to initial proof of concept apps or development prototypes that don't access production or sensitive data. Otherwise, the token-based authentication classes available in the Azure SDK should always be preferred when authenticating to Azure resources.
Authentication in server environments
When hosting in a server environment, each application should be assigned a unique application identity per environment the application is run in. In Azure, an app identity is represented by a service principal, a special type of security principal intended to identify and authenticate apps to Azure. The type of service principal to use for your app depends on where your app is running.
|Apps hosted in Azure||Apps hosted in Azure should use a Managed Identity service principal. Managed identities are designed to represent the identity of an app hosted in Azure and can only be used with Azure hosted apps.
For example, a Django web app hosted in Azure App Service would be assigned a Managed Identity. The Managed Identity assigned to the app would then be used to authenticate the app to other Azure services.
|Apps hosted outside of Azure
(for example on-premises apps)
|Apps hosted outside of Azure (for example on-premises apps) that need to connect to Azure services should use an Application service principal. An Application service principal represents the identity of the app in Azure and is created through the application registration process.
For example, consider a Django web app hosted on-premises that makes use of Azure Blob Storage. You would create an Application service principal for the app using the App registration process. The
Authentication during local development
When an application is run on a developer's workstation during local development, it still must authenticate to any Azure services used by the app. The two main strategies for authenticating apps to Azure during local development are:
|Create dedicated application service principal objects to be used during local development||In this method, dedicated application service principal objects are set up using the App registration process for use during local development. The identity of the service principal is then stored as environment variables to be accessed by the app when it is run in local development.
This method allows you to assign the specific resource permissions needed by the app to the service principal objects used by developers during local development. This makes sure the application only has access to the specific resources it needs and replicates the permissions the app will have in production.
The downside of this approach is the need to create separate service principal objects for each developer that works on an application.
|Authenticate the app to Azure using the developer's credentials during local development||In this method, a developer must be signed-in to Azure from either the Azure Tools extension for VS Code, the Azure CLI, or Azure PowerShell on their local workstation. The application then can access the developer's credentials from the credential store and use those credentials to access Azure resources from the app.
This method has the advantage of easier setup since a developer only needs to login to their Azure account from VS Code or the Azure CLI. The disadvantage of this approach is that the developer's account likely has more permissions than required by the application, therefore not properly replicating the permissions the app will run with in production.
Use DefaultAzureCredential in an application
pip install azure-identity
Then, the following code example shows how to instantiate a
DefaultAzureCredential object and use it with an Azure SDK client class, in this case a BlobServiceClient used to access Blob storage.
from azure.identity import DefaultAzureCredential from azure.storage.blob import BlobServiceClient # Acquire a credential object credential = DefaultAzureCredential() blob_service_client = BlobServiceClient( account_url="https://<my_account_name>.blob.core.windows.net", credential=credential)
DefaultAzureCredential will automatically detect the authentication mechanism configured for the app and obtain the necessary tokens to authenticate the app to Azure. If an application makes use of more than one SDK client, the same credential object can be used with each SDK client object.
Sequence of authentication methods when using DefaultAzureCredential
DefaultAzureCredential implements a chain of credential providers for authenticating applications to Azure resources. Each credential provider is able to detect if credentials of that type are configured for the app.
DefaultAzureCredential sequentially checks each provider in order and uses the credentials from the first provider that has credentials configured.
The order in which
DefaultAzureCredential looks for credentials is shown in the diagram and table below.
|Application service principal||DefaultAzureCredential reads a set of environment variables to determine if an application service principal (application user) has been set for the app. If so,
This method is most often used in server environments but can also be used when developing locally.
|Managed Identity||If the application is deployed to an Azure host with Managed Identity enabled,
This method is only available when an application is hosted in Azure using a service like Azure App Service, Azure Functions, or Azure Virtual Machines.
|Visual Studio Code||If the developer has authenticated to Azure using the Visual Studio Code Azure Account plugin,
|Azure CLI||If a developer has authenticated to Azure using the
|Azure PowerShell||If a developer has authenticated to Azure using the
|Interactive||If enabled, DefaultAzureCredential will interactively authenticate the developer via the current system's default browser. By default, this option is disabled.|
Submit and view feedback for