An implementation review of MCP HTTP authorization using the November 2025 specification and OAuth standards. It explains resource indicators, token audience validation, forbidden passthrough, and the authorization decisions needed before tool execution.
At a glance
Key findings
- A token's audience and its scopes answer different questions. The MCP server must verify that the token was intended for its own resource.
- Forwarding an incoming token to a downstream API is not an acceptable shortcut for a correctly designed MCP authorization relationship.
- Transport authorization does not decide whether a particular user may perform every proposed tool action. That decision still needs an explicit policy.
Name the parties before choosing the credential
A cloud assistant can involve a person, an application, an MCP server, an authorization server, and a downstream service. The application may request a document search while the MCP server calls a separate storage API. Those relationships are easy to collapse into a single statement that the user is authenticated. That statement does not establish who issued each credential, which service may accept it, or which operation it permits.
The November 25, 2025 MCP specification defines an authorization flow for HTTP-based transports. Authorization is optional for MCP implementations overall, and the document directs stdio implementations toward credentials obtained from the environment instead of this HTTP flow. This article therefore reviews protected HTTP MCP services, not every program that exposes an MCP interface. [1]
Draw the identities separately in the design review. For each credential, record its issuer, intended recipient, permissions, lifetime, and storage location. Then identify which component validates those properties. This inventory is a proposed review technique, not evidence that any particular integration is secure. It often exposes an ambiguity before that ambiguity becomes a permissive fallback in code.
Bind the token to the intended resource
Audience and scope are different dimensions. A token might permit a read operation while still being intended for the wrong service. Conversely, a token intended for the correct service can lack the permission required for a write. Review both dimensions instead of treating the presence of any bearer token as sufficient evidence of authority.
RFC 8707 defines resource indicators so a client can identify the protected resource for which it seeks an access token. The MCP specification requires the resource parameter in authorization and token requests, and it requires the MCP server to validate that accepted tokens were issued for that server. The authorization server's support and the resource server's enforcement both matter. [1][3]
Make the intended identifier explicit in configuration and tests. A deployment with several environments or several MCP endpoints should not depend on a vague convention that any token from the same organization is acceptable everywhere. Decide whether identifiers represent a host or a more specific resource path, and verify that discovery metadata, token issuance, and server validation agree on that decision.
One resource boundary at a time
The MCP token ends at the MCP resource boundary. Downstream execution has its own authorization decision.
Source. MCP authorization and security guidance, RFC 8707, and RFC 9700 [1]-[4].
Method. Original simplified HTTP authorization sequence. Downstream policy is an explicit design step, not a claim that MCP prescribes one universal delegation mechanism. No integration test was executed.
Accessible table and figure data
| Step | Authority being checked | Review question |
|---|---|---|
| Resource discovery | Identity of the protected MCP service | Does the metadata identify the intended service? |
| Authorization request | Resource owner grant | Which resource and scopes are requested? |
| Token issuance | Authorization server decision | Is the token bound to that resource? |
| MCP request | Incoming token validity and audience | Does the server reject a token intended elsewhere? |
| Tool policy | Caller authority for this action | Are the resource and destination permitted? |
| Downstream request | Separate downstream authorization | Whose authority does the downstream service see? |
| Step | Authority being checked | Review question |
|---|---|---|
| Resource discovery | Identity of the protected MCP service | Does the metadata identify the intended service? |
| Authorization request | Resource owner grant | Which resource and scopes are requested? |
| Token issuance | Authorization server decision | Is the token bound to that resource? |
| MCP request | Incoming token validity and audience | Does the server reject a token intended elsewhere? |
| Tool policy | Caller authority for this action | Are the resource and destination permitted? |
| Downstream request | Separate downstream authorization | Whose authority does the downstream service see? |
Do not turn the MCP server into a token relay
Suppose an integration accepts a storage-service token and forwards it unchanged to storage. That may appear convenient because the caller already has a credential. It also makes the MCP service's own authorization boundary difficult to reason about: the service is accepting authority intended for another recipient rather than validating authority granted to itself.
MCP's security guidance explicitly forbids token passthrough and discusses the resulting accountability and trust-boundary problems. Its guidance is not satisfied by checking that a token-shaped string exists or that a downstream request happened to succeed. The incoming credential must be appropriate for the MCP resource that accepts it. [2]
Treat downstream access as a separate design decision. Depending on the service, that could involve a supported delegation flow, a separate user authorization relationship, or a narrowly scoped service identity. Document whose authority the downstream request represents and how the originating user is authorized. Do not invent a universal token-exchange mechanism where the downstream provider has not documented one.
Authorize the business action after the transport check
A valid MCP token does not establish that every model-proposed argument is acceptable. A tool may support sending a file, changing a policy, or opening an incident. The operation still needs rules about permitted resources, destinations, tenants, and consequences. Put those checks where execution occurs, with trusted inputs that cannot be replaced by a persuasive sentence in retrieved content.
For an illustrative document-sharing tool, require the application to establish the caller, identify the selected document, and check the intended recipient against the sharing policy. A model-generated recipient address is an input to that decision, not proof of consent. If the action requires confirmation, present the actual destination and the data involved, then bind the confirmation to that specific action.
Keep the audit record equally explicit. Record the requesting identity, authorized resource, policy decision, tool operation, and outcome using identifiers appropriate for the organization's privacy requirements. Avoid recording bearer tokens. This proposed record makes it possible to distinguish an authorized action that failed from an action that should never have been allowed to execute.
Review consent and callback handling together
Consent can fail as a design boundary if a proxy treats a previous approval as permission for a different client or redirect destination. The MCP security guidance describes confused-deputy risks for proxy servers and calls for client-specific consent handling. Review the complete relationship rather than evaluating the consent screen in isolation. [2]
OAuth's security best current practice requires exact registered redirect matching, with a defined localhost exception, and establishes protections against authorization-code injection and related attacks. Public clients must use PKCE. Those requirements support a correctly bound authorization transaction; they are not a substitute for inspecting the requested scopes and the resource that will receive the token. [4]
A useful review follows one authorization from initiation to callback and token use. Check which client initiated it, what the user saw, where the authorization response can return, and how the application rejects a mismatched or replayed transaction. Keep this exercise defensive and use a disposable test client. There is no need to publish a working credential-stealing demonstration to explain the failure mode.
Test denial as part of the integration contract
An integration test that only proves a tool works with a valid token is incomplete. Add benign negative cases for a token intended for another resource, an expired token, insufficient permissions, a changed redirect, and a downstream operation outside the caller's authority. The expected outcome should identify the component that rejects the request and confirm that no tool side effect occurred.
Test the normal path alongside those failures. A secure boundary should still allow the intended task with the intended authority. If a client responds to denial by broadening permissions automatically, retrying forever, or switching to a shared administrative credential, the test has exposed a workflow problem rather than a harmless inconvenience. Define the acceptable recovery behavior before release.
Retain a compact receipt containing the specification version, sanitized configuration, test identities, expected decisions, actual outcomes, and remaining unsupported cases. No such integration test was performed for this article. The deliverable here is a review model: keep each credential attached to its intended resource, and keep every consequential action attached to an explicit authorization decision.
Method and provenance
Review of the cited protocol specification, security guidance, and IETF publications on August 28, 2026, with an original authorization sequence and proposed negative tests.
No MCP implementation, OAuth provider, token-validation path, or downstream tool was tested. The analysis targets the specified HTTP authorization model and does not claim every implementation conforms.
AI assistance. AI assistance was used to research sources, draft and structure the article, and prepare the visual specification. No human technical review is claimed.
Published under the Cloud Security Desk organizational byline. Read the series policy.
References
- MCP Authorization specification version 2025-11-25 Model Context Protocol. Accessed .
- MCP Security Best Practices versioned documentation Model Context Protocol. Accessed .
- RFC 8707 Resource Indicators for OAuth 2.0, February 2020 IETF. Accessed .
- RFC 9700 Best Current Practice for OAuth 2.0 Security, January 2025 IETF. Accessed .