You are building a multi-agent assistant that helps employees query their own Microsoft Graph mail and calendar. Downstream tools must only see data the signed-in user is already allowed to access. Agents run as Azure-hosted services and call Graph on the user’s behalf. Which authentication pattern should you implement for the agent-to-Graph calls?
Select an answer to reveal the explanation.
Short Explanation
Correct answer: B. When agents act for a signed-in user, the OAuth 2.0 on-behalf-of flow lets the middle-tier agent exchange the inbound user token for a Graph token under delegated permissions. That preserves user-scoped access and auditability. App-only client credentials with broad application permissions (A) would let the agent read mailboxes the user should not reach. ROPC with passwords (C) is discouraged and unsafe in agent sessions. Long-lived PATs in memory (D) create secret sprawl and weak lifecycle control. OBO plus least-privilege delegated scopes is the right multi-agent auth pattern here.
Full Explanation
Multi-agent solutions often need user impersonation without collecting credentials. OAuth 2.0 on-behalf-of (OBO) is designed for middle-tier services: the client presents a user access token; the agent service exchanges it (with its own confidential client credentials) for a new token scoped to downstream APIs such as Microsoft Graph. Delegated permissions ensure Graph enforces the same access the user already has. Application-only flows (A) elevate to tenant-wide access and break least privilege for personal data. Resource owner password credentials (C) are legacy, incompatible with modern MFA, and must not be stored in agent state. Personal access tokens (D) are difficult to rotate, hard to attribute, and unsuitable as primary agent auth. Combine OBO with short token lifetimes, continuous access evaluation where available, and careful handling of token caches so session memory does not become a secret store.