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?

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.

The correct mapping pairs delegated expense submission with Authorization Code Flow, unattended nightly consolidation with Client Credentials Flow, and corporate Entra ID federated sign-in with Authorization Code Flow using OpenID Connect and Entra ID as the federated identity provider.

Delegated expense submission requires the agent to act on behalf of a specific employee. Authorization Code Flow is designed 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.

Unattended nightly consolidation has no user involved — it is a background automation that runs as a system process. 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.

Corporate Entra ID federated sign-in describes federated identity — employees log in using existing corporate Entra ID credentials rather than creating separate accounts in the expense system. This is Authorization Code Flow using OpenID Connect, 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.

The answer that uses Client Credentials for delegated expense submission, Authorization Code for nightly consolidation, and SAML Bearer Assertion for Entra ID sign-in is incorrect. Client Credentials for delegated submission 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. Authorization Code also does not fit nightly consolidation because it expects an interactive user to authenticate and consent. SAML Bearer Assertion is not the described OpenID Connect/Entra ID federated sign-in pattern.

The answer that uses Implicit Flow for delegated expense submission, Client Credentials for nightly consolidation, and Authorization Code with PKCE for Entra ID sign-in is incorrect because 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. Its background mapping is appropriate, but its federated sign-in mapping is less precise because it does not explicitly identify Entra ID as the federated identity provider using OpenID Connect.

The answer that uses Resource Owner Password Credentials (ROPC) for delegated expense submission, Client Credentials for nightly consolidation, and Authorization Code with PKCE and Entra ID as the identity provider for Entra ID sign-in is incorrect because ROPC 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. Its background mapping is appropriate, and its federated sign-in mapping is close, but the ROPC choice disqualifies the whole answer.

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.