The lock-status API in Azure API Management is protected only by a subscription key passed in the query string. What should the security engineer recommend for stronger inbound authentication?

The lock-status API in Azure API Management that is protected only by a subscription key in the query string needs stronger inbound authentication: add validate-azure-ad-token or validate-jwt so callers present an Entra-issued (or otherwise trusted) JWT, retaining the subscription key only as a product metering or tracking layer if still needed. Identity-based token validation binds the call to an application or user principal instead of a photocopiable shared secret in the URL. For a municipal lock-status surface, that shift reduces credential replay and ties access to Entra lifecycle controls.

Keeping subscription-key-only validation and publishing the key in the municipal open-data portal fails by concept: publishing a shared key maximizes exposure and keeps authentication as a static secret rather than an identity token. Replacing APIM with App Service Authentication and deleting all APIM products and subscriptions fails because the scenario asks to strengthen APIM inbound authentication, not to abandon API Management’s product and policy model wholesale. Moving the subscription key from the query string into a longer-lived named value password and skipping token validation fails: relocating a static secret does not provide Entra JWT authentication or fix the trust model.

Exam caveat: subscription keys are useful for products, quotas, and analytics but are not a substitute for validate-azure-ad-token / validate-jwt when the exam asks for stronger API authentication. Operational check: attach an inbound validate-azure-ad-token or validate-jwt policy to the lock-status API, require a valid audience and issuer, confirm a call with only a subscription key fails, confirm a call with a proper Entra token succeeds, and rotate any previously published query-string keys.