Introduction:
In modern cloud-native applications, securing APIs is paramount. Azure API Management (APIM) provides a robust platform for managing and securing APIs, and when combined with Azure Entra ID (formerly Azure Active Directory), it offers enterprise-grade security. In my previous article on C# Corner, ‘Securing Azure API Management with DefaultAzureCredential and Zero-Trust Architecture,’ I demonstrated how to build a Blazor client application that consumes APIs protected by APIM using DefaultAzureCredential.
This article extends that implementation by introducing a comprehensive integration testing approach. While the previous article focused on building the actual client application, this article demonstrates how to create automated tests to validate APIM endpoints protected with Azure Entra ID authentication. This testing strategy is crucial for ensuring your API security policies work correctly and for implementing continuous integration and deployment (CI/CD) pipelines.
The Critical Importance of API Testing:
API testing is a fundamental aspect of modern software development, especially for cloud-based microservices architectures. Here’s why API testing is indispensable:
Validation of Security Policies: When APIs are protected with Azure Entra ID and complex authentication mechanisms, it’s essential to verify that only authorized requests succeed and unauthorized requests are properly rejected. Manual testing alone is insufficient for this level of validation.
Regression Prevention: As your API evolves, automated tests ensure that new changes don’t break existing security configurations or functionality. This is particularly important when modifying APIM policies or updating authentication requirements.
Documentation Through Code: Well-written integration tests serve as living documentation, showing developers exactly how to authenticate and interact with your APIs. This is invaluable for onboarding new team members and maintaining consistency across development teams.
CI/CD Pipeline Integration: Automated API tests enable continuous integration and deployment by validating that APIs work correctly before deployment to production. This catches issues early in the development cycle.
Performance Baselines: Integration tests can help establish performance baselines and detect degradation over time, ensuring your APIs maintain acceptable response times under authentication overhead.
Cost Efficiency: Finding bugs in production is significantly more expensive than catching them during development. Automated testing reduces the risk of production issues and associated costs.
The Postman Limitation:
Postman is an excellent tool for API testing and has been the go-to choice for many developers. However, when working with Azure’s identity and authentication ecosystem, Postman has significant limitations:
No DefaultAzureCredential Support: Postman does not support Azure.Identity’s DefaultAzureCredential class, which provides a unified authentication approach across development and production environments. DefaultAzureCredential automatically chains multiple authentication methods including Visual Studio credentials, Azure CLI, Managed Identity, and more.
Manual Token Management: In Postman, developers must manually acquire access tokens using OAuth flows, copy them, and paste them into request headers. This process is:
– Time-consuming and error-prone
– Requires token refresh every hour (typical token lifetime)
– Doesn’t work well for automated testing scenarios
– Cannot leverage developer credentials from Visual Studio or Azure CLI
No App Role Validation: Azure Entra ID uses app roles (application permissions) for service-to-service authentication. Postman cannot easily simulate requests with specific app roles without complex manual token manipulation.
Limited Automation: While Postman supports collection runners and Newman for automation, it lacks the integration with development environments and CI/CD pipelines that xUnit test projects provide.
Environment-Specific Challenges: DefaultAzureCredential works differently in development (using Visual Studio or CLI) versus production (using Managed Identity). Postman cannot replicate this behavior, making it difficult to test the same authentication flow across environments.
No Access to Azure SDK: Postman doesn’t have access to Azure SDKs, which means you cannot test code paths that include Azure-specific functionality alongside API calls.
The Solution:
xUnit Integration Tests with DefaultAzureCredential
To address these limitations, we’ve created a comprehensive xUnit test project that directly integrates with Azure.Identity.
Get the complete code from my GitHub repository
The test project (EntraID-APIM-IntegrationTests) is organized with the following structure:
ApimTestFixture.cs: A shared test fixture that implements IAsyncLifetime, providing centralized configuration and authentication setup for all tests. This fixture:
– Loads configuration from appsettings.json
– Creates and configures DefaultAzureCredential with specific credential chain
– Initializes HttpClient with proper base address
– Acquires and attaches access tokens to HTTP requests
Models Directory: Contains data transfer objects (DTOs) that match the API response structures:
– WeatherForecast.cs: Model for weather data
– User.cs: Model for user endpoint testing
Test Classes:
– WeatherApiIntegrationTests.cs: Tests for GET /weather/forecast endpoint
– UsersApiIntegrationTests.cs: Tests for POST /weather/users endpoint
Configuration: appsettings.json stores APIM base URL, tenant ID, API scope, and endpoint paths.
How DefaultAzureCredential Works in the Test Project
The DefaultAzureCredential implementation in our test project follows this configuration:
Visual Studio Credential (Primary): When running tests from Visual Studio or the dotnet test command, it uses the Azure account signed into Visual Studio (Tools > Options > Azure Service Authentication). This provides a seamless developer experience.
Azure CLI Credential (Fallback): If Visual Studio credentials are unavailable, the command falls back to using Azure CLI credentials (obtained by running ‘az login’). This is useful for command-line scenarios and CI/CD pipelines. Tenant-Specific Authentication: The credential is configured with a specific tenant ID to ensure tokens are acquired from the correct Azure Entra ID tenant.
Automatic Token Management: Unlike Postman, the credential automatically handles token acquisition, refresh, and expiration. Tests never require manual token management.
The code demonstrates the credential configuration:
credential = new DefaultAzureCredential(new DefaultAzureCredentialOptions
{
TenantId = TenantId,
ExcludeEnvironmentCredential = true,
ExcludeWorkloadIdentityCredential = true,
ExcludeManagedIdentityCredential = true,
ExcludeVisualStudioCredential = false,
ExcludeVisualStudioCodeCredential = true,
ExcludeAzureCliCredential = false,
ExcludeAzurePowerShellCredential = true,
ExcludeInteractiveBrowserCredential = true
});
Test Implementation Details:
Each test follows the Arrange-Act-Assert pattern and validates different aspects of the API:
Authentication Tests: Verify that DefaultAzureCredential successfully acquires tokens with the correct scope (api://{api app-id}/.default).
Endpoint Availability Tests: Ensure endpoints return HTTP 200 OK status codes for authenticated requests.
Response Structure Tests: Validate that API responses contain expected properties and data types.
Business Logic Tests: For the weather endpoint, verify temperature conversions (Celsius to Fahrenheit). For the user endpoint, confirm that posted data is correctly echoed back.
Multiple Request Tests: Execute multiple sequential requests to verify token reuse and validate behavior across different inputs.
Benefits of This Approach
Seamless Developer Experience: Developers no longer need to manually manage tokens. Simply sign in to Azure in Visual Studio and run tests.
Production-Like Testing: The same DefaultAzureCredential code that works in tests works in production applications (switching to Managed Identity automatically).
Prerequisites for Running Tests
Azure Entra ID Configuration:
– App Registration with API permissions
– Client application with appropriate app roles assigned
– Tenant ID and Client ID configured
Developer Authentication:
– Sign into Azure in Visual Studio (Tools > Options > Azure Service Authentication)
– OR run ‘az login’ in Azure CLI with the correct tenant
APIM Configuration:
– API published in APIM
– Policies configured for JWT validation
– Backend service or mock responses configured
Test Configuration:
– Update appsettings.json with the correct TenantId, Scope, and BaseUrl
– Ensure endpoint paths match APIM configuration
Summary:
This integration testing approach addresses the limitations of traditional API testing tools, such as Postman, when working with Azure’s authentication ecosystem. By leveraging DefaultAzureCredential in xUnit tests, we achieve automated, repeatable testing without manual token management, seamless integration with developer workflows, production-like authentication testing, compatibility with CI/CD pipelines, and comprehensive validation of security policies.
This builds upon my previous article on securing APIM with DefaultAzureCredential by introducing a robust testing layer. Together, these approaches provide a complete solution for building and validating secure, cloud-native APIs in Azure. The client application demonstrates how to build production-ready applications, while the integration tests ensure those applications work reliably and securely.
