Part 2: Authentication needs in this example scenario

Previous part: Introduction and background

In this example scenario, the main application has three distinct authentication requirements:

• Azure Key Vault

  The application must authenticate with Azure Key Vault to retrieve a securely stored API key needed to call a third-party service.

• Third-party API

  Once the application retrieves the API key, it uses the key to authenticate with the external third-party API.

• Azure Queue Storage

  After processing the request, the application must authenticate with Azure Queue Storage to enqueue a message for asynchronous or deferred processing.

These tasks require the app to manage three sets of credentials:

• Two sets for Azure resources (Key Vault and Storage)

• One set for an external service (third-party API)

Key authentication challenges

Building secure cloud applications requires careful handling of credentials, especially when multiple services are involved. This example scenario presents several critical challenges:

• Circular dependency on Key Vault

  The application uses Azure Key Vault to securely store secrets, such as third-party API keys or Azure Storage credentials. However, to retrieve those secrets, the app must first authenticate with Key Vault. This situation creates a circular problem: The app needs credentials to access Key Vault, but you must store those credentials securely. Without a secure solution, this problem could lead to hardcoded credentials or insecure configurations in development environments.

• Secure handling of third-party API keys

  After retrieving the API key from Key Vault, the application must use it to call an external third-party service. Handle this key with extreme care:

  • Never hardcode it in source code or configuration files
  • Never log it to stdout, stderr, or application logs
  • Hold it only in memory and access it at runtime, just before use
  • Dispose of it promptly after the request is complete

  Failure to follow these practices increases the risk of credential leakage or unauthorized use.

• Securing Azure Queue Storage credentials

  To write messages to Azure Queue Storage, the app typically needs a connection string or shared access token. These credentials:

  • Must be stored in a secure location, such as Key Vault
  • Must not appear in logs, stack traces, or developer tools
  • Should be accessed only through secure runtime mechanisms
  • Require proper RBAC configuration if using managed identity

• Environment flexibility

  The app must run reliably in both local development and cloud production environments, using the same codebase and minimal conditional logic.

  This requirement means:

  • Don't embed environment-specific secrets in the code
  • Don't manually toggle credentials or logic paths
  • Use identity-based authentication consistently across environments

Azure-first authentication with Microsoft Entra ID

As cloud applications scale in complexity and integrate with more services, secure and streamlined authentication becomes essential. Azure offers an Azure-first identity model through Microsoft Entra ID, enabling unified identity management and seamless integration with Azure services for secure, credential-free authentication.

Rather than manually managing secrets or embedding credentials in application code—a practice prone to security risks—Microsoft Entra ID enables apps to authenticate securely by using managed identities.

The key benefits of Microsoft Entra managed identities are:

• No secrets in code

  Applications no longer require hardcoded connection strings, client secrets, or keys.

• Built-in identity for apps

  Azure can automatically assign a managed identity to your app, so it can securely access services such as Key Vault, Storage, and SQL without extra credentials.

• Environment consistency

  The same code and identity model work both in local development and Azure-hosted environments by using the Azure SDK’s DefaultAzureCredential.

Environment-specific identity flow

Applications that use Microsoft Entra ID for authentication benefit from a flexible identity model that works seamlessly in both Azure-hosted and local development environments. The Azure SDK’s DefaultAzureCredential provides this consistency by automatically selecting the appropriate identity method based on the environment.

Azure environment

When you deploy the application to Azure:

• The application automatically gets a managed identity.
• Azure manages token issuance and credential lifecycle internally, so you don't need to handle any secrets.
• The application accesses services by using Role-Based Access Control (RBAC) or Key Vault access policies.

Local development environment

During local development:

• A service principal serves as the app's identity.
• Developers authenticate by using the Azure CLI (az login), environment variables, or Visual Studio/VS Code integrations.
• The same application code runs without any modification - only the identity source changes.

In both environments, Azure SDKs use the DefaultAzureCredential, which abstracts away the identity source and automatically selects the right method.

Best practices for secure development

While you can set secrets as environment variables (for example, via Azure App Settings), this approach has downsides:

• You must manually replicate secrets in local environments.
• There's a risk of secrets leaking into source control.
• You might need extra logic to differentiate between environments.

Instead, use the following approach:

• Use Key Vault to store third-party API keys and other secrets.
• Assign a managed identity to your deployed app.
• Use a service principal for local development and assign it the same access rights.
• Use DefaultAzureCredential in your code to abstract authentication logic.
• Avoid storing or logging any credentials.

Authentication flow in practice

Here's how authentication works at runtime:

• Your code creates a DefaultAzureCredential instance.
• You use this credential to instantiate a client (for example, SecretClient, QueueServiceClient).
• When the app invokes a method (for example, get_secret()), the client uses the credential to authenticate the request.
• Azure verifies the identity and checks whether it has the correct role or policy to perform the operation.

This flow ensures that your app can securely access Azure services without embedding secrets in code or configuration files. It also allows you to seamlessly switch between local development and cloud deployment without changing your authentication logic.

Part 3 - Third-party API implementation >>>