THE USEFUL ANSWER
Review an HTTP MCP server as a protected resource.
Decide whether authorization applies to the whole server or selected tools, publish the required discovery metadata, validate token issuer and audience, restrict scopes to the actual tool action, and return HTTP 401 before protected execution when authorization is missing.
Then test denial paths with the same care as successful calls.
WHAT YOU'LL LEAVE WITH
A release checklist that connects identity, token validation and tool authority without treating a successful OAuth flow as complete access control.
- Per-server and per-tool authorization are different contracts and should be chosen explicitly.
- Issuer validation, resource audience and scope enforcement protect different boundaries.
- A denied protected call must stop before the tool handler performs the action.
01Choose the boundary before the OAuth flow
The MCP Apps authorization guide describes two patterns. Per-server authorization protects every request to the MCP endpoint. Per-tool authorization allows public tools while requiring authorization for named protected tools. The guide requires authorization enforcement at the HTTP boundary so an unauthorized protected call receives HTTP 401 before it reaches the tool implementation. [1]
Swipe or scroll to compare
| Control | Release question |
|---|---|
| Resource | Which MCP server or endpoint is this token meant to access? |
| Issuer | Which authorization server minted and signed the token? |
| Audience | Was the token issued specifically for this protected resource? |
| Subject | Which user or machine identity does the tool act for? |
| Scope | What is the smallest permission needed for this action? |
| Tool check | Does the handler enforce the same authority before side effects? |
02Keep credentials bound to their issuer
The July 2026 MCP specification release strengthened authorization guidance. Clients validate the authorization-server issuer before redeeming a code, and client credentials stay bound to the issuer that minted them. The release also moves toward Client ID Metadata Documents rather than treating dynamic registration as the permanent default. [2]
A valid signature alone is not enough. Validate the expected issuer, the resource audience, expiry and required scope. Do not accept a token intended for a different service or pass the received token to an upstream API as a shortcut.
03Test the denial path before the useful tool
- No token returns HTTP 401 with the resource metadata challenge.
- An expired or invalid token returns 401 and performs no protected action.
- A valid token for another audience is rejected.
- A valid identity without the required scope is rejected.
- A permitted call is constrained to the authenticated subject and resource.
- Tool-level defence-in-depth stops the action if the HTTP layer is misconfigured.
04Record the action, not the bearer token
Keep a receipt containing the subject identifier, tool name, resource, scope decision, result and timestamp. Do not log bearer tokens. The receipt should support review without becoming another credential store. If a tool writes, sends, deletes or spends, require an acceptance or confirmation rule appropriate to that consequence.
This checklist is an implementation aid, not a completed security review. No MCP server, identity provider or protected tool was tested for this article.
FOLLOW THE EVIDENCE
Sources & checks
- MCP Apps: Authorization ↗
Per-server and per-tool authorization patterns, discovery metadata, token verification, HTTP 401 enforcement and defence in depth.
CHECKED 2026-11-10 - Model Context Protocol: The 2026-07-28 Specification ↗
Issuer validation, credential isolation, Client ID Metadata Documents and the current authorization hardening direction.
CHECKED 2026-11-10
Sources stay attached so you can check the argument. Meaningful revisions keep this address.