A team exposes an Azure-hosted web API to makers through a custom connector. The API runs in Azure App Service, and the security team requires every call to carry the calling maker's Microsoft Entra ID identity, with no shared keys stored in connections. How should the developer secure the connector and the API?
Select an answer to reveal the explanation.
Short Explanation
The rule says every call has to carry the maker's own identity, so you need user sign-in on both ends. App Service authentication makes the API demand Entra tokens, and the connector's OAuth 2.0 Entra setting gets each maker one. Keys, IP lists and service accounts all hide who the real caller is.
Full Explanation
Microsoft recommends Microsoft Entra ID for securing APIs behind custom connectors, and App Service authentication can enforce it without writing authentication code in the API. With an Entra app registration for the API, the App Service rejects requests that lack a valid token for that API. The connector is configured for OAuth 2.0 with the Entra ID provider, a client app registration, the API's application ID URI as the Resource URL, and the connector's redirect URL registered on the client app; each maker signs in when creating a connection, so every call carries that maker's identity and no shared secret is stored in connections. A shared access key with API Key authentication puts a reusable secret in every connection and identifies only the key, not the maker. IP restrictions limit network origin but provide no identity, and Power Platform ranges are shared across tenants. Basic authentication with one service account makes every call look like the same user and stores a password. Exam caveat: custom connectors can use a managed identity instead of a client secret for the OAuth client, which removes secret rotation while keeping delegated user sign-in. Operational check: call the API without a token and confirm 401, then call through a maker's connection and confirm the API sees that maker's user principal name.