A Copilot Studio agent is being designed to integrate with a third-party expense management API that requires OAuth 2.0 authentication. Three different integration scenarios are under consideration: (A) The agent must call the expense API to submit expense reports on behalf of individual employees using their own identities; (B) A background agent must run nightly to consolidate all expense data for finance reporting, with no user interaction; (C) The organization manages the expense system and wants employees to log in using their corporate Entra ID credentials via federated identity. Which OAuth 2.0 grant type is most appropriate for each scenario respectively?
Select an answer to reveal the explanation.
Short Explanation and Infographic
OAuth 2.0 grant type selection comes down to one question: is a human user involved? If yes, Authorization Code Flow lets the user prove who they are and delegate access to the agent. If no user is involved (background job), Client Credentials Flow uses the application's own identity. Federating corporate logins is Authorization Code Flow again — just with Entra ID as the identity provider holding the user's credentials.
Full explanation below image
Full Explanation
OAuth 2.0 defines multiple grant types for different authentication contexts. Choosing the correct one is not arbitrary — using the wrong grant type creates security vulnerabilities and operational failures.
Option D is correct because it maps the right grant type to each scenario's trust model.
Scenario A requires the agent to act on behalf of a specific employee. The Authorization Code Flow is designed exactly for this: the user authenticates directly with the expense system's authorization server, consents to the agent acting on their behalf, and receives an access token scoped to their identity. This ensures expense submissions carry the correct employee identity for audit trails and approval workflows.
Scenario B has no user involved — it is a background automation that runs as a system process. The Client Credentials Flow authenticates using the application's own client ID and secret (or certificate), obtaining a token scoped to the application's permissions rather than any individual user. This is appropriate for background jobs, daemons, and service-to-service API calls.
Scenario C describes federated identity — employees log in using their existing corporate Entra ID credentials rather than creating separate accounts in the expense system. This is the Authorization Code Flow using OpenID Connect (OIDC), with Entra ID configured as the identity provider in the expense system. The expense system trusts Entra ID's authentication assertions, allowing single sign-on.
Option A is incorrect because Client Credentials Flow for Scenario A would mean the agent calls the expense API using its own application identity, not the employee's. Expense submissions would appear to come from the application, not the individual employee, breaking audit trails and approval workflows.
Option B is incorrect because the Implicit Flow is deprecated in OAuth 2.0 (RFC 6749 has been superseded by security best practices guidance in RFC 9700) due to access token exposure risks in browser redirects. Modern applications use Authorization Code Flow with PKCE instead of Implicit Flow.
Option C is incorrect because the Resource Owner Password Credentials (ROPC) grant requires the agent to handle the user's raw username and password directly, violating the core security principle of OAuth 2.0 (the application should never see the user's credentials). ROPC is considered an anti-pattern and is disabled by default in Entra ID for enterprise applications.
Exam tip: For AB-620 OAuth questions, know these four grant types: (1) Authorization Code — user-delegated, interactive; (2) Client Credentials — application identity, no user; (3) ROPC — deprecated, avoid; (4) Implicit — deprecated, avoid. Entra ID's on-behalf-of (OBO) flow is a fifth pattern used for middle-tier service calls that propagate user identity.