A security team discovers that an Azure OpenAI deployment is experiencing a credential stuffing attack where attackers cycle through many API keys attempting to find valid ones. Which combination of controls in Azure API Management (APIM) and Microsoft Entra ID provides the most comprehensive protection?
Select an answer to reveal the explanation.
Short Explanation
Here's the deal — you need to replace the static API key model with Entra ID OAuth 2.0 tokens, then enforce them in APIM with validate-jwt. Add Conditional Access for compliant devices, and credential stuffing becomes impractical because attackers need valid tokens and compliant devices, not just stolen keys.
Full Explanation
The correct approach is migrating from API key authentication to Microsoft Entra ID OAuth 2.0 token authentication enforced via APIM validate-jwt policy, with Conditional Access requiring compliant devices. Credential stuffing targets the API key authentication model. Migrating to Entra ID OAuth 2.0 tokens eliminates the static API key attack surface entirely. Enforcing this via APIM validate-jwt policy ensures only valid Entra ID tokens are accepted, and Conditional Access requiring compliant devices adds another verification layer making credential stuffing impractical since attackers would also need valid device compliance. IP filtering to block suspicious IP ranges and Azure OpenAI API key rotation every 30 days is incorrect because IP filtering helps but does not address the core issue of API key authentication being vulnerable; key rotation is reactive, not preventive. APIM rate limiting per subscription key with a threshold of 100 requests per minute is incorrect because rate limiting slows credential stuffing but does not prevent it; it remains vulnerable to distributed, low-volume attacks. Deploying Azure DDoS Protection Standard on the APIM VNet and enabling APIM built-in caching is incorrect because DDoS Protection and caching address availability and performance concerns, not authentication credential stuffing.