An HTTP-triggered Azure Function backs a custom connector used by many makers. The compliance team requires the function to log which individual user made each call and to reject callers who are not signed in to the company tenant, and it does not want a shared secret distributed to makers. Which authentication approach should the developer choose?
Select an answer to reveal the explanation.
Short Explanation
A function key is a house key: it opens the door, but it can't tell you who walked in. When compliance wants each user named and no shared secret handed out, you need Entra sign-in on both sides. Sending an email address as a parameter is a name tag anyone can write.
Full Explanation
Function keys authorize a request by possession of a secret; every caller with the key looks identical, and the key must be distributed to whoever creates a connection, which the compliance team forbids. App Service authentication with Microsoft Entra ID makes the platform validate an Entra token before the function runs and passes the user's claims to the function, so it can log the individual caller and reject anyone without a token from the company tenant. The connector uses OAuth 2.0 with the Entra ID provider, so each maker signs in when creating a connection. Keeping function keys with API Key authentication is a valid and simple pattern when caller identity is not required, but it does not meet either requirement here. Anonymous access with an email parameter lets any caller claim any identity, which is neither authentication nor auditable. The master key grants access to every function and administrative endpoints, so sharing it is the worst form of shared secret. Exam caveat: the function's own authorization level is independent of App Service authentication; with Entra enforced at the platform, the function can use anonymous level internally. Operational check: call the function without a token and confirm 401, then call through a maker's connection and confirm the logs record that maker's user principal name.