Teams often overestimate how much needs to move into the client and underestimate how much can stay stable in the rest of the stack. A better approach is to accept the new authorization grant at the token endpoint, issue the same style of access token already supported, and leave the resource server unchanged. That reduces migration risk and avoids unnecessary rework across downstream services.
Where the client stops and the protocol starts
The common mistake is treating mcp authorization as if the client must absorb all the change. In practice, the client is only one participant in the OAuth-style flow. If the protocol already supports accepting a new grant at the token endpoint and issuing the same style of access token, then much of the enforcement logic stays where it belongs, and the resource server keeps its existing contract.
That matters because authorization design is not just about where a policy check happens. It is about preserving a stable trust boundary, keeping token semantics consistent, and avoiding a client-side redesign that spreads change across every downstream integration. The goal is to move only the minimum necessary control point.
For teams trying to reason about the boundary, MCP Security Guide is useful because it frames MCP around the authorization model, token passthrough, and gateway decisions rather than client rewrites.
Why client-only thinking creates avoidable migration risk
Client-only thinking usually leads to overcorrection: teams redesign the client, then discover they have to preserve compatibility with the same server-side audience, scopes, and token handling anyway. That creates duplicated logic, harder testing, and more places for authorization drift to appear. A cleaner model is to let the token endpoint absorb the new grant while the access token format and resource server behavior remain stable.
This is especially important when the real control objective is delegated access, not new application behavior. If the client becomes the only place where the authorization change lives, every consuming app, tool, or automation path has to be updated in lockstep. That turns a protocol change into an ecosystem change.
Where the authorization model itself needs to be chosen or compared, Authorisation Models Guide helps teams separate model selection from transport handling, and AI Agent Authorisation Guide shows how delegated authority and per-action decisions should be bounded rather than pushed blindly into the caller.
What should remain stable in the rest of the stack
The biggest design win is not client simplicity by itself, but stability elsewhere. If the resource server can continue validating the same kind of token, existing authorization checks, logging, and downstream service assumptions do not need to be rebuilt. That reduces blast radius, especially in systems where multiple services consume the same access token pattern.
Teams also miss that authorization compatibility is often more valuable than maximal client flexibility. The client can request or present the new grant, but the server side should still decide what access is actually issued and consumed. That keeps the policy decision close to the enforcement point and avoids scattering logic across applications that should not each become policy engines.
For implementation detail on the protocol side, the MCP authorization specification is the clearest reference for treating MCP servers as OAuth 2.1 resource servers with audience-bound tokens, while RFC 6749, RFC 8707, and RFC 9728 cover the OAuth grant, resource indicators, and protected resource metadata that keep the server side coherent.
Risk and Threat Considerations
When teams assume the client must carry all authorization change, they often create two risks at once: unnecessary migration complexity and weaker control over who can ask for what. The result can be token confusion, overbroad client privileges, and inconsistent behaviour across environments or tools that were never meant to enforce policy themselves.
Failure mechanism: The client accumulates policy logic that should have stayed centralized at the token endpoint or resource server, which makes authorization harder to verify and easier to misapply across integrations.
Impact: Access rules become brittle, downstream services inherit avoidable rework, and a single client-side mistake can widen exposure across the whole authorization path.
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 |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | MCP authorization still depends on correct token-based authentication at the API boundary. |
| API5 — Broken Function Level Authorization | The question is about keeping authorization enforcement out of the client and at the server boundary. | |
| Recommendation — Validate token issuance and audience handling before exposing MCP access to clients. Enforce function-level checks on the resource server, not in the client. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Stable server-side authorization reduces unnecessary privilege expansion in clients. |
| IA-5 — Authenticator Management | The answer relies on token handling and grant issuance at the authorization boundary. | |
| AC-3 — Access Enforcement | Resource servers should keep enforcing access consistently while clients change grants. | |
| Recommendation — Constrain client-issued access to the minimum permissions required. Manage tokens and grants centrally to avoid client-side credential sprawl. Keep access enforcement at the resource server boundary. | ||
Practitioner Guidance
What to prioritise: Keep the token endpoint and resource server as the primary enforcement points, then let the client adapt only to the new grant shape. If the server contract can remain stable, preserve it.
What to verify: Confirm that the new grant produces the same token semantics the resource server already understands, and that no team has quietly added duplicate authorization logic in the client to compensate for missing server support.
Common mistake: Treating MCP authorization as a client rewrite problem instead of a protocol and token-boundary problem. That usually expands the change surface and makes rollback harder.
Practitioner takeaway: The safest design is the one that changes the least number of enforcement points, because authorization failures become much harder to spot once policy is duplicated in the client.
Related resources from NHI Mgmt Group
- What do teams get wrong when they assume MCP logs are enough for accountability?
- What do teams get wrong when they assume authorization only needs to cover human users?
- What do teams get wrong when they assume authorization can be added after product design?
- What do teams get wrong when they assume identity and authorization can be handled by the same system?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
