A developer is creating a custom connector for an internal REST API that is protected by Microsoft Entra ID. Each maker's calls must carry their own Entra identity, and the API's app registration exposes an application ID URI. How should the developer configure the connector's security?
Select an answer to reveal the explanation.
Short Explanation
For an Entra-protected API you want each maker signing in as themselves, and that's OAuth 2.0 with the Entra provider. You give the connector a client app, point the Resource URL at the API, and register the connector's redirect URL. Pasting tokens by hand works for about an hour, then quietly breaks.
Full Explanation
Custom connectors support OAuth 2.0 with a Microsoft Entra ID identity provider, which Microsoft recommends for APIs secured by Entra ID. The developer registers a client application, grants it delegated permission to the API, and enters the client ID, client secret and the API's application ID URI as the Resource URL on the connector's Security tab. When the connector is saved, it shows a per-connector redirect URL that must be added to the client app registration. Each maker then signs in when creating a connection, and calls carry that maker's token. API Key authentication with a pasted bearer token fails as soon as the token expires and bypasses the sign-in flow, so connections break within hours. Basic authentication with one service account sends a shared password and makes every call look like the same user, defeating per-maker identity. Opening the API to Power Platform IP ranges without authentication removes identity entirely and exposes the API to any tenant's connectors in those ranges. Exam caveat: connectors created before the per-connector redirect URI change may still need the update to unique redirect URL setting. Operational check: create a connection as a test maker, call an operation, and confirm the API logs that maker's identity.