An Azure Functions app must read and update Dataverse rows every 15 minutes with no signed-in user. Security requires that the service not use any person's account, not consume a user license, and not store a user password. Which authentication design meets these requirements?
Select an answer to reveal the explanation.
Short Explanation
Think of an application user as a badge issued to a machine, not a person sharing their keys. Your function proves who it is with its own secret or certificate, and Dataverse decides what it can touch through the security role on that badge. The trap is the old service-account-with-a-password trick, which breaks every requirement in the stem.
Full Explanation
Server-to-server authentication is the supported pattern for unattended services. The developer registers an application in Microsoft Entra ID, then creates an application user in the target Dataverse environment that is linked to that app's client ID and assigns it a security role. At run time the service uses the OAuth 2.0 client credentials flow with a client secret or certificate to obtain an app-only token for the environment URL, so no interactive user, no password and no paid user license are involved. A licensed account with a stored password violates every stated constraint and weakens security by exempting it from multifactor authentication. Reusing an administrator's refresh token ties the service to a person: when that account changes or the token is revoked, the integration fails, and every action is attributed to the administrator. A connection reference is a solution component that points flows and apps at connections; it is not a credential that external code can use to call the Web API. Exam caveat: authentication succeeding does not grant data access; the application user still needs a security role with the right privileges. Operational check: confirm the application user appears in the environment with the expected role and that the function's token request uses the client credentials grant.