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.
How to choose the flow based on who the request is acting for
The decision point is whether the MCP request represents a person or a non-interactive system action. OBO preserves the user as the security principal, which matters when the downstream call should inherit that person’s permissions, consent boundary, and audit trail. Client credentials treat the calling application as the principal, which is the right fit for unattended automation, scheduled tasks, and other system-to-system work.
That distinction is not just semantic. It changes who is authorized, whose consent is relevant, and what investigators will see later in logs and token traces. In practice, teams should start by asking whether the action would still make sense if the originating user were removed from the path.
What changes in access control, audit, and consent
OBO is the better fit when the user’s authority must remain visible end to end, especially for actions that should be attributable to a named person. It is commonly used when an MCP client is acting as a mediator, but the real decision-maker is still the human behind the session. That model supports least-surprise auditing and keeps delegated access aligned with the user’s own entitlements. The MCP authorization model is still important here because the server must validate audience and token handling rather than relying on token passthrough shortcuts, as described in the Model Context Protocol: Authorization specification.
Client credentials shifts the trust boundary. The application owns the credential, the application is accountable for the action, and the permissions should be scoped to what the automation actually needs. That is why machine-to-machine access is usually described in OAuth terms rather than user delegation terms. For the underlying grant mechanics, see the RFC 6749: The OAuth 2.0 Authorization Framework, which defines the client credentials grant used for non-user access.
When teams mix these models, the usual failure is over-attribution or under-attribution. A human action can be logged as if it were a service action, or a service action can be wrongly tied to a user who never reviewed or approved it. That is where approval workflows, token exchange boundaries, and downstream policy evaluation matter more than the protocol label alone.
Where MCP security teams should draw the line
MCP adds a practical wrinkle because the same integration may support both user-driven and automated execution. The right choice often depends on whether the server needs to make authorization decisions on behalf of the caller or simply allow a tool to run without a human in the loop. For teams designing or reviewing these paths, the MCP Security Guide is useful because it ties OAuth-based authorization, token passthrough risks, and gateway design back to the actual MCP operating model.
For human-initiated requests, prefer OBO when the downstream system should inherit the user’s identity and policy context, especially if the action may be reviewed, revoked, or investigated later. For unattended work, prefer client credentials when there is no meaningful end user to preserve, but compensate with narrow scopes, strong credential handling, and explicit ownership of the automation identity. If the workflow needs both patterns, separate them rather than trying to force one token shape to serve every path. The RFC 8707: Resource Indicators for OAuth 2.0 is relevant when token audience scoping has to stay tight to the intended resource.
In other words, OBO answers “whose decision is this?” while client credentials answers “which application is allowed to act on its own?” If the answer is ambiguous, the architecture is usually ambiguous too.
Risk and Threat Considerations
Choosing the wrong flow can flatten accountability, widen privilege, or make a compromised integration harder to detect. OBO can leak user authority into places where the user should never have delegated access, while client credentials can become a high-value standing privilege if the automation credential is too broad or too durable.
Failure mechanism: A shared or over-scoped automation credential can be replayed, reused, or abused without a human approval step, while a poorly implemented OBO path can silently convert delegated user intent into broader service-side access than the user actually expected.
Impact: Investigators lose clean attribution, consent boundaries become unreliable, and a compromise can propagate through MCP-integrated tools with either user-level or application-level authority depending on which flow was chosen and how the token was handled.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Covers service-to-service authentication for client credentials in MCP. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Supports externally facing or delegated user identity in OBO flows. | |
| AU-2 — Event Logging | Needed to preserve audit evidence for whether MCP calls were user or app initiated. | |
| Recommendation — Use IA-9 to authenticate MCP services and automation identities separately from users. Use IA-8 to keep user-bound MCP access attributable to the individual principal. Log the caller identity, token exchange path, and downstream principal for each MCP action. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Directly applies to OAuth-based API and MCP token handling decisions. |
| API5 — Broken Function Level Authorization | MCP tool calls must be authorized for the correct principal and privilege level. | |
| Recommendation — Validate OAuth flows so MCP callers cannot authenticate as the wrong principal. Enforce function-level authorization so MCP tools only execute allowed actions. | ||
Practitioner Guidance
What to verify: Confirm whether the MCP call is truly user-driven or whether the user is only the source of a trigger. If the downstream action must be attributable to a person, use OBO and make sure logs preserve the user identity, consent basis, and token exchange boundary. If the action is autonomous, use client credentials and document the owning service, scope, and rollback path.
Decision rule: If removing the user from the scenario changes the authorization decision, choose OBO. If the action still makes sense as an unattended service operation, choose client credentials. Do not use convenience as the deciding factor, because convenience is how teams end up with either false user attribution or unnecessary standing privilege.
Practitioner takeaway: The safest MCP design is the one that keeps the security principal aligned with the real actor, human for delegated work, application for autonomous work, and never both at once.
Related resources from NHI Mgmt Group
- Guide: NHI Authentication Guide
- How should security teams implement Client ID Metadata Documents?
- How should security teams choose between API keys, Device Flow, and Client Credentials for CLI apps?
- How should security teams decide between RAG and MCP in production AI systems?
- How should security teams decide between leased credentials and remote identities for SSH and Kubernetes access?