Authentication should be enabled on API endpoints hosted in Logic Apps (Preview)

What does the recommendation "Authentication should be enabled on API endpoints hosted in Logic Apps (Preview)" check?

Microsoft Defender for APIs discovers the request-triggered endpoints exposed by your Logic Apps workflows and flags any whose inbound call path enforces no caller identity. In practice that means a Consumption workflow starting with a 'When a HTTP request is received' trigger that still relies only on the default Shared Access Signature key in the URL, or a Standard workflow whose HTTP trigger has no App Service Authentication in front of it. It judges whether a caller must prove who they are, not what the workflow then does. It does not inspect run history, validate the contents of an OAuth token, check connector-level credentials to downstream systems, or cover workflows triggered by sources other than an HTTP endpoint, such as recurrence, Service Bus or Event Grid.

Why does "Authentication should be enabled on API endpoints hosted in Logic Apps (Preview)" matter?

A request-triggered Logic App is a publicly resolvable HTTPS endpoint. When the only gate is the SAS key embedded in the trigger URL, that URL is the credential: anyone who finds it in a browser history, a proxy log, a shared runbook or a leaked screenshot can invoke the workflow directly. Because workflows frequently write to databases, post to Teams or email, move files or call privileged management APIs, an unauthenticated trigger is a remote, unattended action that an attacker can replay at will. The business consequence is data exfiltration or unwanted side effects executed under your tenant's identity, with the requests looking legitimate in logs. Requiring a Microsoft Entra ID token shifts the gate from a guessable URL to an identity you can revoke, condition and audit.

How do I fix "Authentication should be enabled on API endpoints hosted in Logic Apps (Preview)"?

1. For a Consumption workflow, open the logic app, go to Workflow settings, and under Access control configuration set the trigger access control to require OAuth 2.0 with Microsoft Entra ID, then add an authorisation policy whose claims (issuer, audience and your chosen application or tenant) the inbound token must match. A request-trigger endpoint accepts only one scheme, so enabling Entra ID authorisation replaces SAS for that trigger.
2. For a Standard workflow, enable App Service Authentication (EasyAuth) on the logic app and add Microsoft as the identity provider, then choose how unauthenticated callers are handled: az webapp auth update --name <app> --resource-group <rg> --enabled true --unauthenticated-client-action Return401. For a pure HTTP-trigger API, Return401 cleanly rejects callers that present no Entra ID bearer token; RedirectToLoginPage is also valid but 302-redirects browser-less callers instead of rejecting them, so reserve it for interactive endpoints.
3. Enforce the control at scale by assigning the matching built-in policy rather than fixing apps one by one. Look the definition up by display name so you never hardcode a GUID: pid=$(az policy definition list --query "[?displayName=='Authentication should be enabled on API endpoints hosted in Logic Apps'].name" -o tsv); az policy assignment create --name require-logicapp-auth --policy "$pid" --scope /subscriptions/<sub-id>. Bake the same authorisation policy block into your Bicep or ARM workflow templates so new apps ship authenticated by default.

# 1. Enable the Defender for APIs plan on the subscription so onboarded APIs are inspected.
az security pricing create --name Api --tier Standard

# 2. Disable the deprecated direct management endpoint (retired 15 March 2025).
#    'customProperties' on the service controls this gateway behaviour.
az apim update --name apim-prod --resource-group rg-platform \
  --set 'properties.customProperties."Microsoft.WindowsAzure.ApiManagement.Gateway.ManagementEndpoint"=false'

# 3. Re-enable backend certificate chain and name validation on a backend that
#    had it switched off. There is no native 'az apim backend' TLS flag, so PUT
#    the documented 'tls' block via the management API (api-version 2024-05-01).
sub=$(az account show --query id -o tsv)
az rest --method put \
  --uri "https://management.azure.com/subscriptions/$sub/resourceGroups/rg-platform/providers/Microsoft.ApiManagement/service/apim-prod/backends/payments-backend?api-version=2024-05-01" \
  --body '{"properties":{"url":"https://payments.internal/","protocol":"http","tls":{"validateCertificateChain":true,"validateCertificateName":true}}}'

# 4. Ratchet it shut: audit any instance whose management endpoint stays enabled.
#    Look the built-in policy up by display name; never hardcode a definition GUID.
pid=$(az policy definition list \
  --query "[?displayName=='API Management direct management endpoint should not be enabled'].name" -o tsv)
az policy assignment create \
  --name audit-apim-mgmt-endpoint \
  --policy "$pid" \
  --scope "/subscriptions/$sub"