A developer is building a custom connector for an internal REST API that is protected by Microsoft Entra ID. Auditors require every call to run with the identity of the person using the app or flow so that the API can apply that user's own permissions. Which security configuration should the connector use?
Select an answer to reveal the explanation.
Short Explanation
Think of it like a hotel key card: the door checks your card, not the front desk's master key. With OAuth through Entra ID each user signs in once and the connector carries their own token, so the API sees who's actually calling. The trap is the shared key plus a header naming the user, which anyone can fake.
Full Explanation
Custom connectors support several authentication types, and the choice determines whose identity reaches the backend. OAuth 2.0 with the Microsoft Entra ID identity provider makes each connection belong to the user who creates it: the user signs in, the connector obtains a delegated token for the API's resource, and every request carries that token, so the API can authorize against the real caller and audit logs show a true identity. An API key is a shared secret; adding an email header does not prove identity, because any client holding the key can claim to be anyone. Basic authentication with a service account collapses every caller into one identity and forces that account to hold the broadest set of permissions, the opposite of least privilege. Removing authentication and relying on IP restrictions identifies only the platform, not the person, and the shared outbound ranges are used by many tenants. Exam caveat: delegated per-user OAuth is also what lets data policies and conditional access behave consistently for connector users. Operational check: in the connector's security tab confirm OAuth 2.0 with Microsoft Entra ID, the API's resource URL and the client ID, then test with two users and verify the API logs two different principals.