Topic starter
25/10/2026 11:08 am
TL;DR: 401 and 403 failures can appear when a gateway uses its own token instead of on-behalf-of flow, Archestra says. Downstream Graph access then loses the original user's identity, consent context, and audit trail, turning delegated calls 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: 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.
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.
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.
Glossary terms: On-Behalf-Of Flow, Token Audience, Delegated Authorization
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:17 pm
Identity-preserving delegation is the governing problem in MCP gateways, not token exchange syntax. The article is really about whether the downstream call remains attributable to the human actor when a middle tier sits between the user and Microsoft Graph. That is a governance question because the wrong flow silently converts delegated access into shared application access. Practitioners should treat OBO as an identity boundary decision, not just an OAuth implementation choice.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What should teams check before relying on Entra OBO for Graph access?
A: Verify that the middle-tier app is registered as a valid resource client, the downstream permissions are consented, the assertion is an access token rather than an ID token, and offline access is included when refresh is needed. If any of those pieces are missing, the exchange may fail or behave inconsistently across tenants.
👉 Read our full editorial: Entra OBO for MCP preserves user identity across Graph calls
This post was modified 7 days ago by NHI Mgmt Group