OAuth limits the assistant to what the linked account can already do, but that only helps if the underlying account is minimal and the connector exposes narrow actions. If the account is overprivileged, OAuth simply becomes a clean path to too much access. The control failure is excessive delegation, not the protocol itself.
Why OAuth does not remove MCP connector risk
OAuth answers the question “who may the assistant act as,” not “how much that account should be allowed to do.” With MCP, the connector can still expose broad tools, and the linked account may already hold excessive permissions. That means OAuth can authenticate the delegation cleanly while still handing the assistant a very wide blast radius.
OAuth also does not constrain the connector’s own trust assumptions. If the MCP server passes tokens through, maps a single token to many actions, or relies on a permissive upstream account, the protocol is not the weak point. The risk comes from how authorization is delegated, scoped, and enforced after login, which is why narrow scopes and minimal accounts matter as much as the sign-in step.
For the protocol mechanics, the right reference point is the OAuth 2.0 Authorization Framework, but the security outcome depends on how the connector applies that framework in practice. If the assistant can invoke high-impact actions through a broad token or an overprivileged account, OAuth has not reduced risk, it has merely formalised the path to it. When the connector is an MCP integration, the MCP authorization specification is the more relevant layer for understanding audience restriction and token handling.
What actually fails in an overprivileged connector
The failure mode is excessive delegation. A connector can be “properly authenticated” and still be dangerous if the linked identity can read mail, modify records, trigger workflows, or reach production systems far beyond the assistant’s intended task. In that case, the assistant becomes an efficient operator of existing privilege rather than a bounded automation.
This is especially important when the assistant is using long-lived access paths or token passthrough. If the connector forwards the user’s or service account’s token without narrowing audience, scope, or action set, the assistant inherits whatever that token can already do. The control question is therefore not whether OAuth is present, but whether the connector enforces least privilege at the resource and action level.
That is why the OAuth 2.0 Security Best Current Practice matters here: sender-constrained tokens, reduced token exposure, and better handling of delegation paths all reduce the chance that a valid token becomes a broad reusable key. For MCP-specific deployments, the connector should also be compared against the MCP Security Guide because it frames the practical issues around token passthrough, gateways, and narrow authorization.
How to make OAuth safer in MCP integrations
Safer MCP design starts with the account, not the login flow. Use the smallest viable permissions on the linked account, expose only the tools the assistant truly needs, and avoid letting one OAuth grant stand in for broad human equivalence. If the connector can perform multiple unrelated actions, split those into separate scopes, separate accounts, or separate connectors.
The next control is token binding and audience restriction. When possible, prefer sender-constrained or resource-bound designs so the token cannot be replayed elsewhere or reused across unrelated backends. If the connector supports delegated flows, make the delegation explicit and limited rather than treating the assistant as a general-purpose proxy for the signed-in user.
For OAuth design choices, the Resource Indicators for OAuth 2.0 and Demonstrating Proof of Possession specifications are useful because they reduce token overreach and replay risk. If the connector must operate on behalf of a user, token exchange can also help separate the original identity from the delegated capability when used carefully.
Risk and Threat Considerations
OAuth can hide a dangerous trust expansion: a benign-looking consent flow may still give an MCP assistant durable access to data, systems, or workflows that were never meant for autonomous use. The threat is not a broken protocol, it is the abuse of a legitimate delegation path that makes excessive privilege feel normal.
Failure mechanism: The assistant receives a valid token for an overprivileged account, or the connector relays that token to broad backend actions without tightening scope, audience, or action boundaries.
Impact: A single successful grant can expose mailboxes, tickets, files, admin functions, or production workflows, and any compromise of the token or connector can turn into rapid lateral movement and high-volume misuse.
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, OWASP Agentic AI Top 10 and OWASP API Security Top 10 address 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-5 — Authenticator Management | OAuth token lifecycle and exposure risk depend on managing delegated credentials safely. |
| AC-6 — Least Privilege | The risk comes from overprivileged accounts and overly broad connector actions. | |
| IA-9 — Identification and Authentication (Non-Organizational Users) | MCP/OAuth delegation often authenticates external or non-human clients to backend services. | |
| Recommendation — Manage delegated tokens with short lifetimes, rotation, and revocation controls. Limit each connected account to the minimum permissions needed for the assistant task. Use strong client authentication and bind delegated access to the intended client and audience. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The connector risk arises when the delegated non-human account has more privilege than the task needs. |
| NHI-07 — Long-Lived Secrets | OAuth tokens or related secrets can become durable abuse paths if not tightly bounded. | |
| Recommendation — Audit and reduce non-human account privileges before granting connector access. Prefer short-lived, narrowly scoped credentials and revoke unused grants quickly. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | An assistant with valid OAuth access can still abuse delegated authority if privilege is excessive. |
| Recommendation — Constrain agent authority so delegated identity cannot exceed the approved action scope. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | A connector that exposes too many actions can authorize functions the assistant should not reach. |
| API2 — Broken Authentication | OAuth does not help if token handling or client authentication is weak in the connector path. | |
| Recommendation — Enforce function-level authorization on every connector action, not just login. Require robust client authentication and reject bearer-token handling that enables replay. | ||
Practitioner Guidance
What to verify: Confirm that the linked account is genuinely minimal and that the connector exposes only the actions required for the use case. If the answer is “the account already has broad access,” treat OAuth as a delivery mechanism for risk, not as a mitigation.
Decision rule: If the assistant can cause material business impact through the connector, require narrower scopes, separate delegated identities, or explicit action gating before rollout. If you cannot describe the allowed action boundary in one sentence, the connector is too broad.
Practitioner takeaway: OAuth reduces credential friction, but it does not reduce privilege by itself; the security outcome depends on whether the connector and the underlying account are both constrained to the smallest believable delegation path.
Related resources from NHI Mgmt Group
- Guide: OAuth 2.0 and OpenID Connect Guide for Identity Teams
- Why do non-human identities create compliance risk even when policies exist?
- Why do non-human identities create more audit risk than human accounts?
- Why do non-human identities create audit risk in modern environments?
- Why do collaboration tools create such a large secrets risk?