OAuth only answers how a client authenticates after registration. If the registration step is open, an attacker can still create clients, request scopes and interact with tools before downstream controls have enough context to distinguish legitimate use from abuse.
Why dynamic registration changes the risk picture
OAuth can be implemented correctly and still leave a meaningful exposure if the client registration step is open or weakly governed. The control then protects a known client after registration, but it does not by itself stop an attacker from creating a new client, requesting permissions, or probing how tools respond before the environment has enough context to judge intent.
That matters because dynamic MCP clients are not just passive API consumers. They can become the front door for tool access, scope negotiation, and delegated actions, so the security boundary shifts from “can this client authenticate?” to “should this client have been allowed to exist and ask for these privileges in the first place?”
For a protocol-level view of that boundary, the MCP authorization specification shows why MCP servers treat authorization as a resource-server problem, while OAuth 2.0 itself only defines how clients and servers complete the grant flow.
What an attacker gains from open registration
Open registration lowers the cost of abuse. An attacker does not need to steal a legitimate client first if they can spin up a fresh one, choose a registration profile that fits the target, and use the normal OAuth flow to obtain tokens. Even when scopes are correctly enforced, the attacker may still get enough access to enumerate tools, test boundaries, or reach high-value actions that are only weakly separated by scope design.
This is especially risky in MCP-style deployments because client identity is often not the same as user identity, and the same tooling layer can be reached by many transient clients. If registration is dynamic, the platform must rely on discovery, policy, and downstream trust decisions to decide whether the request is legitimate. That creates an abuse window before reputation, inventory, or review catches up.
The problem is not unique to MCP. The OAuth core standard RFC 6749 defines the authorization framework, but it does not eliminate the governance burden around who may register clients, what metadata they may present, or how much access they can request on first contact.
Why correct OAuth still leaves room for abuse
When OAuth is used correctly, it validates the grant path, token issuance, and authorization decision. It does not automatically solve client vetting, registration abuse, token audience confusion, or the problem of granting real access to an untrusted requester. That is why security teams must treat registration policy, client inventory, and tool-level authorization as separate controls rather than assuming OAuth closes the loop.
In practice, the highest-risk failure mode is not a broken token exchange. It is a technically valid but socially untrusted client receiving enough access to interact with tools, disclose metadata, or trigger side effects before a human or policy engine can intervene. The correct question is not only “was the OAuth flow valid?” but also “was this client eligible to start the flow at all?”
The OAuth 2.0 security best current practice is relevant here because modern OAuth guidance increasingly emphasizes sender-constrained tokens, reduced token replay risk, and tighter deployment decisions around how tokens and clients are accepted.
Risk and Threat Considerations
Open or dynamic registration expands the attack surface from token abuse to identity creation abuse. An attacker can use that window to create throwaway clients, request broad scopes, and explore tool behavior under legitimate-looking OAuth sessions, which makes the abuse harder to spot than a direct credential theft event.
Failure mechanism: The platform trusts a newly registered client before it has enough signal to distinguish a legitimate integration from a malicious one, so valid OAuth tokens are issued to an unvetted actor and then used against exposed tools or actions.
Impact: This can produce unauthorized tool invocation, excessive scope grants, persistence through repeatedly re-registered clients, and higher blast radius when the client layer is used to reach sensitive downstream services or data.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while OWASP ASVS and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Dynamic MCP clients can gain tool access through valid auth flows. |
| Recommendation — Constrain newly registered clients before they can request sensitive scopes or tool actions. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | OAuth correctness still depends on how clients are issued and trusted. |
| Recommendation — Harden client registration and token issuance paths so untrusted clients cannot bootstrap access. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Machine and agent clients still need strong registration and auth controls. |
| Recommendation — Require governed registration and short-lived credentials for non-human clients. | ||
| OWASP ASVS | V10 — OAuth and OIDC | The question concerns OAuth flow security and its limits around client trust. |
| Recommendation — Validate OAuth deployment assumptions beyond token correctness, especially client trust and scope handling. | ||
| NIST Zero Trust (SP 800-207) | PR.AA-05 — Identity and Access Management | Dynamic clients need least privilege and conditional trust before tool access. |
| Recommendation — Apply least-privilege access and policy checks before granting tool-facing client access. | ||
Practitioner Guidance
What to verify: Separate “OAuth is correct” from “client registration is controlled.” You want to know who can register, what metadata must be supplied, whether registrations are approved or federated, and whether newly registered clients are rate-limited or sandboxed until they earn trust.
Decision rule: If a client can be created without prior trust, treat registration itself as a security control point and require allowlisting, policy checks, or human approval before the client can request meaningful scopes or reach production tools.
What good looks like: A newly registered client is visible in inventory, bound to a known owner or registration path, limited to minimal scopes, and constrained so that early abuse cannot immediately reach high-impact tool actions.
Practitioner takeaway: Correct OAuth proves the flow is valid; it does not prove the client deserved to enter the flow. The real control question is whether registration, scope issuance, and tool access are all gated tightly enough to absorb untrusted first contact.
Related resources from NHI Mgmt Group
- Why do shared OAuth clients increase risk in Remote MCP deployments?
- Why does Slack MCP increase data exposure risk even when permissions are inherited correctly?
- Why does Dynamic Client Registration increase risk for MCP environments with autonomous clients?
- Why do OAuth-connected AI agents increase breach risk in enterprise environments?