August 26th, 2025
like1 reaction

Azure Authentication Changes in Semantic Kernel Python

Dmytro Struk
Senior Software Engineer

In previous versions of the Semantic Kernel Python, the default fallback authentication mechanism for Azure services like AzureChatCompletion was DefaultAzureCredential from the Azure Identity library. This provided a convenient way to authenticate without explicitly passing credentials, especially during development. However, with the latest package version 1.36.0, this fallback is being removed to encourage more secure and explicit authentication practices. If your code relied on this default behavior, you may encounter errors after updating, and you’ll need to make minor code adjustments to continue using credential-based authentication.

This post explains the reasoning behind this change, the potential issues you might face, and how to update your code accordingly. For more details on Azure authentication options, check out the Azure Identity library documentation.

Why This Change is Required

DefaultAzureCredential is designed primarily for local development environments, where it simplifies authentication by attempting a chain of common developer credentials (such as Azure CLI, Azure PowerShell, or Visual Studio Code sign-ins) until one succeeds. While this is helpful for quick prototyping, it introduces several risks and limitations in production:

  1. Unpredictable Behavior: It tries multiple authentication methods in sequence, which can lead to delays, unexpected failures, or reliance on credentials that aren’t consistently available across environments.
  2. Interactive Authentication Fallback: By default, it can prompt for interactive browser-based login, which is unsuitable for automated, headless production applications running on servers or in cloud environments.
  3. Security and Best Practices: Production scenarios benefit from explicit, dedicated credentials like managed identities or service principals, which offer better control, auditing, and security. Using a broad fallback like DefaultAzureCredential can mask configuration issues and doesn’t align with principles of least privilege.

For these reasons, we recommend using specific credential types tailored to your deployment environment in production to ensure reliability and security.

Changes in the Latest Version and Potential Errors

Starting with the new SDK version, the implicit use of DefaultAzureCredential as a fallback has been removed. This means that if your code doesn’t explicitly provide an authentication method (such as an API key, AD token, or credential object), initialization will fail.

Users updating to this version who previously relied on the default fallback might see a ServiceInitializationError with the message: Please provide either api_key, ad_token, ad_token_provider, credential or a client. This error indicates that the SDK now requires you to explicitly pass one of the supported authentication options during service creation.

This change promotes better coding practices by making authentication explicit, reducing hidden dependencies, and aligning with Azure’s security guidelines.

How to Update Your Code

To resolve this, update your code to pass an explicit authentication method. If you want to continue using a credential-based approach (similar to the old fallback), you can instantiate a specific credential type from the Azure Identity library and pass it to the service constructor.

For example, change from the old implicit fallback:

chat_service = AzureChatCompletion()

To an explicit credential, such as AzureCliCredential (or any other suitable type like ManagedIdentityCredential for Azure-hosted apps):

from azure.identity import AzureCliCredential

chat_service = AzureChatCompletion(credential=AzureCliCredential())  # Or use another credential type

Other options include providing an api_key, ad_token, ad_token_provider, or a pre-configured client. Choose the one that best fits your environment.

Remember to import the necessary credential class from azure.identity and ensure your environment is set up accordingly (e.g., Azure CLI logged in for AzureCliCredential).

Summary

This update to the Semantic Kernel Python removes the DefaultAzureCredential fallback to encourage explicit and secure authentication, addressing potential issues in production while maintaining flexibility. By making a small code change, you can avoid initialization errors and align with best practices.

We’re always interested in hearing from you. If you have feedback, questions, or want to discuss further, feel free to reach out to us and the community on the discussion boards on GitHub! We would also love your support—if you’ve enjoyed using Semantic Kernel, give us a star on GitHub.

Author

Dmytro Struk
Senior Software Engineer

0 comments