Entra OBO in MCP gateways: why the token exchange matters

TL;DR: Entra OBO for MCP changes the token request from "call Graph as the gateway" to "call Graph as the signed-in user", which preserves per-user permissions and audit trails across middle-tier requests, according to Archestra. For identity teams, the core issue is not token plumbing but whether downstream access retains user-bound accountability instead of collapsing into shared service identity.

Editorial analysis by NHI Mgmt Group, based on content published by Archestra: “Entra On-Behalf-Of flow for MCP, explained”.

Key questions

Q: What breaks when an MCP gateway uses its own token instead of on-behalf-of flow?

A: The downstream API sees the gateway as the actor and loses the original user's identity, consent context, and audit trail.

Q: Why does the audience claim matter in delegated Microsoft Graph access?

A: The audience claim tells Entra which resource the token was issued for.

Q: How do security teams decide between OBO and client credentials in MCP?

A: Use OBO when a real user is behind the request and downstream access must stay tied to that person.

Practitioner guidance

• Define the delegation boundary Document which calls must preserve the signed-in user's identity and which calls should remain application-scoped before wiring the gateway to Graph.
• Validate the token exchange inputs Check that the gateway sends the user's access token, requested_token_use=on_behalf_of, and the correct downstream scope instead of trying to reuse a Graph audience token.
• Separate user-delegated and app-only paths Use OBO only for requests that must remain attributable to a person, and keep scheduled jobs or unattended automations on client credentials.

Bottom line: Entra OBO for MCP is about preserving the signed-in user's identity through a middle tier, not simply getting a token that works.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →