Choose whose authority each call carries

Learning objective

Distinguish application-only credentials, direct user impersonation, and delegated OAuth 2.0 on-behalf-of flows; enforce token audience, consent, and user/agent delegation boundaries.

Core idea

For a multi-agent application, decide whether an operation uses the application’s own authority or a user’s delegated authority. A scheduled inventory agent can act without a signed-in user. An assistant reading an employee’s personal records must preserve that employee’s permissions. A middle-tier API that calls another API for the employee needs a token issued for that downstream API.

A user ID does not turn application-only access into delegation, and forwarding a token does not change its audience. The receiver must validate the token and authorize its principal.

See 0.6 for the foundation and 4.1.3 for restricting authorized agent-call paths. Here the deciding question is which credential flow carries authority across each hop.

How it works

Use application-only authority for unattended work

The Microsoft identity platform’s OAuth 2.0 client credentials flow authenticates an application without a user. Its token request uses grant_type=client_credentials and a scope containing the resource identifier with /.default appended. For Microsoft Graph, that value is https://graph.microsoft.com/.default. All scopes in that request must refer to one resource.

The application authenticates using its configured credential, which can be a secret, certificate, or federated credential. Permission comes from the resource’s application authorization model, such as application permissions assigned through Entra or a resource-maintained access control list. Application permissions require administrator authorization; they are not the signed-in user’s delegated scopes.

The flow does not issue refresh tokens. The application obtains another access token using its own credential. This is not a reason to store a user’s refresh token for an unattended job.

In Foundry A2A connections, --auth-type agentic-identity selects agent authority, while --auth-type project-managed-identity selects the project’s shared identity. Both require the corresponding principal’s downstream permissions. Prefer the agent-specific principal when agents have different authority requirements; see 4.1.1. Selecting an identity determines who calls, not what that principal is automatically allowed to do.

Distinguish user passthrough from token exchange

“Direct user impersonation” in this objective describes a call executed using the user’s authority. It is not a Microsoft identity platform grant type with that name. One concrete Foundry mechanism is user identity passthrough: the A2A connection documentation exposes --auth-type user-entra-token with --audience for managed user identity passthrough.

The A2A authentication page also describes OAuth identity passthrough. Agent Service generates a consent link, the user signs in to the underlying service, and the service stores access and refresh tokens scoped to that user-agent combination. Tool calls carry the user’s access token; a refresh token obtains another access token when needed. A custom OAuth connection uses --auth-type oauth2 with --authorization-url, --token-url, --client-id, --client-secret, and --scopes.

The token must still be intended for the remote service. Passthrough is not permission to relay any token found in the conversation. Treat target-issued OAuth tokens and tokens intended for your middle-tier API differently. The latter belong in an OBO exchange when that middle tier needs a downstream token.

For Foundry OAuth identity passthrough, the user needs Foundry Agent Consumer on the calling project or agent; Foundry User also works but includes development permissions. When the target is another Foundry agent, the user also needs access there. Consent to an external scope does not grant Foundry endpoint access, and a Foundry role assignment does not grant external-service permissions.

Exchange a user token with on-behalf-of

Microsoft Entra’s OAuth 2.0 on-behalf-of (OBO) flow connects a user-facing client, a confidential middle-tier API A, and a downstream API B. The client sends API A a user access token whose aud identifies API A. API A authenticates itself to the token endpoint and submits that token as the assertion. Entra returns a different access token intended for API B.

The documented token request uses grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer, requested_token_use=on_behalf_of, the incoming assertion, and the downstream scope, together with the middle tier’s client authentication. API A sends the returned token to API B. This exchange preserves delegated user access while changing the token’s intended receiver.

The input assertion must have the middle tier as its audience. API A must reject a token meant for Microsoft Graph rather than trying to redeem it as its own assertion. OBO works for user principals and delegated scopes, not an app-only service-principal token. An unattended service uses client credentials instead of trying to transform its own application token into user delegation.

In Foundry’s attended flow, Agent Service exchanges the user’s token for a token carrying both the agent identity and the user’s delegated permissions, limited to resources the user has consented to and is authorized for; see 0.6.

The middle tier cannot display a consent prompt during the downstream exchange. For combined consent, list the client in the middle tier’s knownClientApplications manifest property and request .default: the client’s consent prompt covers both its permissions and the middle tier’s required downstream permissions. A tenant administrator can instead grant admin consent for the middle-tier application.

When Conditional Access returns an error such as interaction_required with a claims challenge, reply to the client with HTTP 401 and a WWW-Authenticate header carrying the error and challenge. The client obtains a token that satisfies the challenge rather than retrying its cached token. Do not substitute broad application credentials for missing consent or required user interaction.

API A therefore trades a user token meant for itself for one intended for API B, or hands a Conditional Access challenge back to the client.

Enforce the receiving API’s contract

For a custom receiving API, validate signature and issuer with appropriate token-validation middleware; Microsoft names Microsoft.Identity.Web for ASP.NET and ASP.NET Core. Then authorize the intended aud, tenant tid, subject, and permitted operation. The scp claim carries delegated scopes. It is absent from app-only tokens, so do not silently interpret its absence as unlimited user access.

Keep the flow choice attached to the operation. An endpoint that supports both app-only and delegated requests needs explicit authorization paths for each. A user-authorized read should not gain app-only write authority because an agent selected another connection. Keep refresh tokens and connection credentials outside prompts and bind their use to the configured user-agent or application context.

Key distinctions and trade-offs

The three choices differ in the authority presented to the receiver:

Passthrough can fit a tool connection with user-specific OAuth credentials. OBO fits a middle-tier API chain. Application-only access fits unattended work. Choose from the required principal and trust relationship rather than treating one flow as universally stronger.

Architecture / decision scenario

An employee assistant supports a scheduled inventory scan, a user-specific external repository lookup, and a benefits query through an internal API.

Run inventory under an application or agent principal with approved application authorization. It has no employee session, so request its target token with client credentials rather than attempting OBO. Authorize only the inventory operations that the job requires.

Configure repository lookup with user OAuth identity passthrough. The employee consents to the configured scopes, and the connection uses that employee’s target-service token. Check the employee’s Foundry consumer access and remote repository permissions separately. Another employee’s conversation must not select the stored token for this user-agent pair.

For benefits, the frontend obtains a token for the internal middle tier. That API validates it and uses OBO to obtain a token for the benefits API, which authorizes the delegated employee. A token with the wrong audience is rejected. Missing consent or a Conditional Access challenge goes back to the client for resolution. Neither failure permits retrying with the inventory agent’s application-only authority.

Common exam traps

• Treating a user ID in an app-only request as delegated authorization.
• Calling “direct impersonation” a documented OAuth grant type.
• Forwarding API A’s token to API B without a valid audience or exchange.
• Using an app-only token as a user OBO assertion.
• Confusing Foundry consumer access with downstream OAuth consent.
• Escalating a denied delegated call into application-only access.

What to remember

Application-only access uses the application’s own authority. Passthrough uses a user token issued for the target. OBO exchanges a user token for a downstream delegated token through an authenticated middle tier. Preserve audience, consent, tenant, and operation checks at every receiving API.

Knowledge check

References

• Microsoft, Microsoft identity platform and the OAuth 2.0 client credentials flow
• Microsoft, Microsoft identity platform and OAuth 2.0 on-behalf-of flow
• Microsoft, Connect to Agent2Agent endpoints
• Microsoft, Agent2Agent authentication in Foundry Agent Service
• Microsoft, Secure applications and APIs by validating claims
• Microsoft, Microsoft identity platform access tokens
• Microsoft, Agent identity concepts in Microsoft Foundry