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.
At a glance
What this is: This is a practical explainer of Entra on-behalf-of flow for MCP gateways, showing why the correct downstream token exchange preserves the signed-in user's identity when a middle-tier service calls Microsoft Graph.
Why it matters: It matters because IAM teams building AI gateways need to prevent shared service accounts from replacing user attribution, consent, and auditability in delegated access flows.
Context
The governance gap is not the gateway itself but the assumption that a middle-tier service can safely call downstream APIs with its own identity and still preserve user accountability. In an Entra-backed MCP flow, that assumption fails because the gateway is only the relay, not the actor of record.
On-behalf-of exchange is the mechanism that keeps the original user attached to the downstream request instead of collapsing the call into a shared service principal. That distinction matters whenever an AI app sits between a human user and a Microsoft-protected resource, because auditability depends on the downstream token representing the user, not the intermediary.
For teams standardising MCP authorization, the real design choice is whether the platform should preserve user context hop by hop or intentionally operate as an application identity. OAuth token exchange and delegation is the broader pattern; Entra OBO is its Microsoft-specific implementation.
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. That usually leads to 401 or 403 failures when the audience does not match, and it also creates governance problems because logs show a shared service identity rather than the person who initiated the action.
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. In an OBO exchange, the gateway must present a user token minted for the gateway itself so Entra can issue a new token for Graph. If the audience is already Graph, there is nothing to exchange and the flow no longer fits the middle-tier pattern.
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. Use client credentials when there is no human subject, such as a scheduled job or unattended automation. The decision is about identity attribution, not convenience, because the two flows produce different audit and consent outcomes.
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.
Technical breakdown
Why a gateway token cannot be reused for Graph
An access token is audience-bound. If the gateway receives a token minted for itself, it cannot forward that token to Microsoft Graph because Graph will reject the audience mismatch. That is why the question to Entra must be changed from “give me a token to call Graph” to “give me a token to call Graph as the user who is calling me now.” In OBO, the gateway presents the user token as an assertion and asks Entra to mint a new token for the downstream API. The new token is distinct, scoped correctly, and still carries the original subject. See the NHI Authentication Guide. See the NHI Authentication Guide.
Practical implication: Treat audience alignment as a hard requirement in MCP gateway design, not a configuration detail.
What the OBO exchange actually sends to Entra
The token endpoint call uses grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer, the user's access token as the assertion, requested_token_use=on_behalf_of, and the downstream scope such as https://graph.microsoft.com/.default. Those four values define the exchange. The access token must be the input because it contains the audience claim that proves the token was issued for the calling app. An ID token is not a substitute, and a missing or wrong audience breaks the exchange before downstream permissions are even evaluated.
Practical implication: Validate the assertion type, requested_token_use value, and target scope before debugging Graph failures.
Why OBO keeps audit trails attached to the user
OBO does not create a new user. It preserves the signed-in subject while allowing the middle tier to obtain a downstream token that Graph can accept. That means delegated permissions, consent state, and logs remain user-bound instead of being recorded as a shared service account action. In an MCP architecture, this is the difference between “the service account read the mailbox” and “Alice read her mailbox through an AI app.” The control value is governance, not convenience. Identity attribution survives the relay because the exchange is explicitly user-delegated rather than app-only.
Practical implication: Use OBO wherever per-user access and per-user audit evidence must survive a middle tier.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Shared service identity is the failure mode Entra OBO is designed to avoid. When a gateway calls Graph with its own credentials, the log trail stops reflecting who asked for the action. That breaks accountability, consent interpretation, and access review evidence. The practical takeaway is that user context must survive every hop where a human is still the real business actor.
On-behalf-of is the correct pattern when the middle tier is a relay, not the decision-maker. The user owns intent, the gateway brokers the request, and the downstream API enforces delegated authorization. That separation is what lets Entra preserve least-privilege semantics without turning the AI layer into a privileged super-account. Practitioners should design the delegation chain around who should remain visible in audit, not around which flow is easiest to wire.
Credential-bearing middle tiers are where identity governance becomes visible or disappears. Once a gateway can act on behalf of a user, the question is no longer whether the app has access, but whether the access remains bounded to the original user's authority. In Entra OBO deployments, that boundary is the difference between defensible delegation and a hidden shared-identity pattern. Practitioners should make that boundary explicit in architecture reviews.
From our research library:
- 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.
- Read next: OAuth Token Exchange and Delegation Guide
What this signals
MCP gateway architectures will keep pushing identity teams toward delegation models that preserve the end user across multiple hops instead of collapsing the session into a shared backend account. The programme question is no longer whether an app can reach the API, but whether the API can still prove who initiated the call.
Delegation fidelity: this is the control boundary that determines whether downstream access remains attributable to the user or is reclassified as application activity. Teams building AI-enabled gateways should assume that any place the user context is dropped becomes a governance gap, not just an implementation shortcut.
As enterprises move more human tasks into AI-mediated flows, the practical test for IAM becomes whether logs, consent, and entitlement checks still point back to the person who asked for the action. Token exchange and delegation is the pattern to standardise when per-user auditability has to survive a middle tier.
For practitioners
- 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.
- Check consent before rollout Confirm that the downstream permissions needed by the gateway are already consented in the tenant, because .default only expands to permissions that exist.
Key takeaways
- Entra OBO for MCP is about preserving the signed-in user's identity through a middle tier, not simply getting a token that works.
- The main governance risk is identity collapse, where downstream calls appear to come from a shared service account instead of the initiating user.
- Teams should validate token audience, consent state, and assertion type before assuming delegated Graph access will behave as intended.
Related NHI Mgmt Group resources: OAuth Token Exchange and Delegation Guide · NHI Authentication Guide · MCP Security Guide · Agentic AI Identity Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article is about selecting the correct authentication flow for a middle-tier MCP gateway. |
| NHI-10 — Human Use of NHI | The gateway is acting on behalf of a human user through a non-human identity flow. | |
| Recommendation — Use NHI-04 to ensure delegated tokens, audiences, and assertions are validated before downstream API calls. Apply NHI-10 to keep human intent, consent, and attribution visible when a gateway brokers access. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | The flow authenticates a service and its delegated downstream use in a non-organizational context. |
| Recommendation — Use IA-9 to govern how external and delegated identities are authenticated across the MCP relay chain. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on preserving the right authorization context when a gateway exchanges tokens. |
| Recommendation — Apply PR.AA-05 to keep delegated permissions aligned with the user rather than the intermediary service. | ||
Key terms
- On-Behalf-Of Flow: A token or session pattern where one identity acts for another while preserving evidence of delegation. For agents, the value is not just access propagation. It is the ability to show that the action was performed under a specific authority and within a specific scope.
- Token Audience: Token audience is the service or workflow a token was intended to authenticate. A valid token can still be wrong if the audience does not match the endpoint receiving it. Audience checks preserve purpose separation and stop one identity artefact from being reused across unrelated access paths.
- Delegated Authorization: A model in which an application is allowed to act on a user’s behalf after explicit approval. In SaaS environments, delegated authorization is powerful but risky because excessive scope or weak revocation can turn a routine integration into durable non-human access.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org