What should teams do first when adding OAuth to an MCP server?

Start by defining the server’s actual authorization boundary: which user actions, tools, and data paths need delegated access, and which do not. Then map those requirements to OAuth scopes and token handling so the MCP server does not inherit custom authentication logic that is hard to audit or revoke.

Define the authorization boundary before you touch OAuth settings

The first step is to decide exactly what the mcp server is allowed to do on behalf of a user, and what it must never inherit. That means separating user actions, exposed tools, and data paths into a clean delegated-access boundary before you choose flows, scopes, or token formats. For MCP, that boundary is the difference between a manageable OAuth integration and an opaque custom auth layer.

That boundary should be written in terms of concrete server behavior: which tools can read data, which can write, which can call upstream systems, and which should remain out of scope. If the boundary is vague, OAuth scopes will be too broad, token handling will drift, and the server can become a confused deputy instead of a constrained resource server.

Map the boundary to scopes, audiences, and token handling

Once the boundary is explicit, map it to the smallest useful set of OAuth scopes and resource restrictions. The practical goal is to keep the server from accepting generic bearer tokens for everything, because that makes revocation, audit, and blast-radius control much harder. For MCP, token handling should reflect the actual resource being accessed, not just the presence of a signed-in user.

Use this step to decide whether a request needs delegated user access, server-to-server access, or no OAuth-mediated access at all. Good scope design should tell an operator, in hindsight, why a token existed, what it could reach, and what should happen when it is revoked. If that answer is not obvious, the scope model is still too loose.

For the protocol layer, the authorization model in the Model Context Protocol: Authorization specification is the right reference point, because it treats MCP servers as OAuth 2.1 resource servers with audience-bound tokens rather than open token passthrough endpoints. That is the architecture teams should align to when defining the first authorization boundary.

Why this matters before custom authentication grows into technical debt

If teams skip the boundary-setting step, they usually end up encoding authorization policy inside application logic, gateway rules, or ad hoc token checks. That creates an implementation that is difficult to audit, easy to overextend, and awkward to revoke cleanly when a user, tool, or integration changes. The server then inherits trust it was never meant to have.

A second failure mode is overgeneralised access. If one token can cover many tools and data paths, compromise of that token becomes a high-value event even when the initial feature set looked narrow. The safer pattern is to define access by task and audience first, then let OAuth carry only the minimum delegation needed for those tasks.

For the underlying protocol mechanics, RFC 6749: The OAuth 2.0 Authorization Framework remains the base standard for how delegated authorization should be structured, while RFC 8707: Resource Indicators for OAuth 2.0 helps constrain tokens to the intended resource rather than the whole server surface. For MCP deployments that need discovery of protected-resource metadata, RFC 9728: OAuth 2.0 Protected Resource Metadata supports a cleaner, more explicit authorization posture.

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 and OWASP API Security Top 10 define the specific risk controls and attack patterns relevant to this topic.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-04 — Insecure Authentication	MCP OAuth setup is about avoiding weak delegated authentication design.
	NHI-05 — Overprivileged NHI	The question is about defining the smallest authorization boundary for server access.
	NHI-07 — Long-Lived Secrets	Token handling and revocation are central to avoiding durable bearer exposure.
Recommendation — Use scoped OAuth flows that avoid custom authentication shortcuts and reduce token abuse risk. Limit server scopes and audiences to the minimum set of delegated actions needed. Prefer short-lived, revocable tokens and avoid durable secret-based access paths.
OWASP API Security Top 10	API2 — Broken Authentication	OAuth is the server authentication and delegation mechanism being introduced.
	API5 — Broken Function Level Authorization	The server must separate which tools and actions are allowed under delegation.
Recommendation — Bind authentication to the intended resource and reject generic token reuse. Authorize each MCP tool or function explicitly rather than trusting a single login state.

Practitioner Guidance

What to prioritise: Start with a written access matrix that names the user action, the MCP tool, the downstream data path, and the token audience for each one. If you cannot explain one of those four items clearly, the OAuth design is not ready.

What to verify: Confirm that each scope maps to a real business task, not to a convenience shortcut, and that revocation removes access where you expect it to. The test is whether you can remove one permission without breaking unrelated tools or leaving hidden access behind.

Common mistake: Do not treat OAuth as a wrapper around existing custom authentication logic. That usually preserves the worst part of the old design, which is broad implicit trust, while adding a new layer of tokens that is harder to reason about.

Practitioner takeaway: The safest first move is to define the server’s delegated-access boundary before designing the OAuth flow, because scope quality and token handling can only be as good as the authorization model underneath them.