MCP client
Acts on behalf of a resource owner. It discovers metadata, registers through an approved mechanism, uses PKCE and requests authority for a specific canonical MCP resource.
Field guide / MCP authorization assurance
MCP authorization security: bind every token to its intended resource.
A remote MCP server is an OAuth resource server, not a transparent token pipe. The safe design discovers trusted metadata, binds authorization to the canonical resource, validates audience and issuer, minimizes scopes, separates downstream credentials and preserves explicit user consent.
Direct answer
Client token → MCP server only
For an HTTP MCP server, discover the protected resource and authorization server, request the smallest scopes for the current operation, include the exact resource parameter, and validate issuer, audience, expiry and scope on every request. Token passthrough is forbidden: when the MCP server calls a downstream API, it uses a separate token issued for that API.
The authorization boundary
MCP server
Acts as the OAuth resource server. It validates every inbound token and applies operation-level authorization before returning data or invoking a tool.
Authorization server
Authenticates the principal, records consent and issues a token bound to the intended MCP resource and scopes. It can be operated separately from the MCP server.
Downstream API
Is a separate resource boundary. The MCP server acts as its client and obtains a separate upstream token; the inbound MCP token never becomes an ambient credential for that API.
Seven controls for the 2026-07-28 specification
Classify the transport and resource
Decide whether the server is remote HTTP or local stdio, define the canonical MCP resource URI and identify every downstream API boundary.
Publish and validate discovery metadata
For protected HTTP servers, use OAuth Protected Resource Metadata and validated authorization-server metadata rather than user-supplied endpoint guesses.
Register and bind the client
Prefer Client ID Metadata Documents or controlled pre-registration, bind credentials to their issuer and validate exact redirect URIs. Dynamic Client Registration is deprecated in the 2026-07-28 specification.
Protect the authorization response
Use PKCE, state, HTTPS or localhost redirects and authorization-response issuer validation before redeeming a code.
Bind tokens and minimize scopes
Send the resource parameter, validate audience, issuer, expiry and required operation scopes on every request, and use bounded step-up authorization instead of catch-all grants.
Separate downstream authority
Never pass the MCP client token through to a third-party API. Obtain a separate upstream token and preserve per-client consent and attribution.
Prove revocation and evidence
Test 401, 403, scope upgrade, logout and revocation paths; redact tokens and record attributable decisions without treating session IDs as authorization.
What changed in 2026-07-28
Authorization response mix-up defense
Authorization servers should return iss; clients validate it against the issuer recorded from trusted metadata before redeeming the code.
CIMD becomes the preferred direction
Dynamic Client Registration is deprecated and retained for backward compatibility. Client ID Metadata Documents or controlled pre-registration should be evaluated first.
Issuer binding is explicit
Client credentials are bound to the issuer that created them. Reusing them across authorization servers crosses a trust boundary the protocol now names directly.
Headers improve control-plane visibility
Streamable HTTP requests carry Mcp-Method and Mcp-Name, giving gateways and rate limiters a protocol-aware input without parsing JSON bodies.
Failure patterns to reject
Token passthrough
The server accepts a client-supplied third-party token and forwards it unchanged, bypassing the MCP resource boundary and weakening attribution.
Generic audience
A token for “api” or another service is accepted because signature validation succeeded even though the MCP server is not the intended resource.
Confused deputy
A proxy with a static upstream client identity reuses consent or authority for a different MCP client without a distinct, visible approval decision.
Scope accumulation without friction
A client requests every scope up front or retries step-up indefinitely, turning a narrow operation into durable ambient authority.
Session ID as identity
An implementation ties authorization to Mcp-Session-Id, even though the identifier is untrusted protocol state rather than proof of identity.
Secrets in URLs or logs
Tokens appear in query strings, redirects, traces or error details, extending the credential into systems that were never authorized to hold it.
Evidence to verify
- Protected Resource Metadata and authorization-server metadata retrieved from trusted, canonical locations.
- Exact canonical resource URI, accepted issuers, audience validation rule and per-operation scope map.
- PKCE, state and authorization-response issuer validation with negative tests for mix-up and redirect mismatch.
- A trace showing 401 for invalid or expired tokens and 403 plus a bounded scope challenge for insufficient authority.
- Separate credential lineage for the MCP client→server token and every server→downstream API token.
- Proof that token passthrough is impossible, secrets are redacted and revocation changes live behavior.
- Per-client consent evidence for any MCP proxy that shares a static upstream OAuth client.
Local stdio is a different boundary
The MCP authorization specification applies to HTTP-based transports. It says a stdio implementation should not run this HTTP OAuth flow and should obtain credentials from its environment instead. That is not permission for ambient authority: isolate process credentials, scope them to one provider and purpose, keep them out of tool responses and logs, and prove their revocation path.
If a local proxy exposes stdio tools backed by a remote account, model both boundaries: host→local process and local process→provider. Do not describe a local transport as authentication for the upstream service.
Framework status and limits
- The normative reference used here is the Model Context Protocol specification revision 2026-07-28.
- The OWASP MCP Top 10 was in beta release and pilot testing when verified on August 11, 2026. It is not a final standard.
- This guide is a defensive design and assurance aid, not certification, legal advice or proof that an implementation is secure.
- Active validation against a real system requires owner authorization and written Rules of Engagement.
Primary sources
Continue the review
Direct answers
What is the most important MCP authorization rule?
Bind each access token to the MCP server it was issued for, validate it on every request and never forward that inbound token unchanged to a downstream API. The MCP server should obtain a separate downstream token for its own upstream client role.
Why is token passthrough unsafe in an MCP server?
Token passthrough erases the boundary between the MCP resource server and the downstream resource. It can bypass audience-dependent controls, weaken attribution and let a token issued for one service be replayed through another. The MCP authorization specification forbids accepting or transiting tokens not intended for the server.
What is the confused deputy problem in MCP?
An MCP proxy becomes a confused deputy when a malicious client abuses the proxy's trusted relationship or static upstream client identity to obtain or use authority the user did not grant to that client. Per-client consent, exact redirect validation and separate token audiences reduce this risk.
Should a local stdio MCP server implement the HTTP OAuth flow?
The MCP 2026-07-28 authorization specification says stdio implementations should not use the HTTP authorization specification and should retrieve credentials from the environment instead. Those credentials still need least privilege, isolation, secure storage, redaction and revocation.
Is the OWASP MCP Top 10 a final standard?
No. As verified on August 11, 2026, the OWASP MCP Top 10 is in beta release and pilot testing. It is a useful living taxonomy, not a final standard, certification or substitute for the normative MCP specification and system-specific threat modeling.