Files

T

retoor 251c3dc2ba research: mcp-client-support subject (106 sources, 3 conclusions)

- wire spec: lifecycle, stdio + Streamable HTTP transports, tools,
  utilities, legacy SSE, versioning, changelog (14 Tier 1)
- client ecosystem: Claude Code/VS Code/Cursor/Codex configs,
  mcp-remote, Smithery, registries, Glama (12 Tier 1)
- security/ops: authorization draft, trust model, poisoning,
  rug pulls, production hardening (12 Tier 1) + 68 Tier 2 cards
- conclusions: minimal stdlib client on 2025-11-25, normalizer +
  resolver agent for pasted configs/GitHub URLs, untrusted-until-
  consent trust model; nothing built yet
- audit PASS (14 subjects, 797 sources, 32 conclusions)

2026-10-18 19:23:02 +02:00

4.3 KiB

Raw Blame History

Authorization - Model Context Protocol

Metadata

Field	Value
Institute	Molodetz Institute - Research & Retrieval Division
Subject	mcp-client-support
Document type	Source Dossier
Tier	1
Source title	Authorization - Model Context Protocol
Source URL	https://modelcontextprotocol.io/specification/draft/basic/authorization
Source publisher / author	MCP specification authors (modelcontextprotocol.io)
Source type	standard
Source date (published)	Unknown - not stated (draft revision; fetched Oct 2026)
Date researched	2026-10-18
Researched by	tai (agent), model: Claude Sonnet 5, on behalf of retoor
Research method	gather-subagent direct page fetch, parent synthesis from evidence pack
Confidence	High
Status	Active

Summary

The draft MCP authorization specification layers MCP auth on OAuth 2.1 plus a set of RFCs for metadata, dynamic registration, and resource indicators. Authorization is OPTIONAL for MCP implementations: HTTP transports SHOULD conform, while STDIO transports SHOULD NOT follow the spec and should get credentials from the environment instead. The hard client rules are RFC 8707 resource indicators on every authorization and token request, strict audience binding in both directions, and issuer validation against authorization-response mix-up.

Key findings

"Authorization is OPTIONAL for MCP implementations": HTTP-based transports SHOULD conform to the spec, but "Implementations using an STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment."
The spec builds on OAuth 2.1 draft (draft-ietf-oauth-v2-1-13) plus RFC 6750 (Bearer usage), RFC 8414 (authorization server metadata), RFC 7591 (dynamic client registration), RFC 8707 (resource indicators), RFC 9728 (protected resource metadata), RFC 9207 (issuer identification), and CIMD (Client ID Metadata Documents).
"MCP clients MUST implement Resource Indicators for OAuth 2.0 as defined in RFC 8707": the resource parameter "MUST be included in both authorization requests and token requests" and "MUST use the canonical URI of the MCP server".
Audience binding is mandatory in both directions: "MCP clients MUST NOT send tokens to the MCP server other than ones issued by the MCP server's authorization server", and "MCP servers MUST NOT accept or transit any other tokens."
Scope step-up flow: on insufficient_scope the client computes "the union of the client's previously requested scope set and the scopes from the current challenge", then retries "no more than a few times".
Authorization-response mix-up defense: clients MUST record the issuer and validate iss per RFC 9207 before sending the code to any token endpoint; "A future revision... is expected to upgrade authorization server inclusion of iss from SHOULD to MUST."
Client registration priority: Client ID Metadata Documents are preferred; DCR "is deprecated and retained for backwards compatibility".

Pros / strengths

Normative and specific: the MUST/MUST NOT rules on resource indicators and audience binding give the client an exact implementation checklist.
Explicitly scopes STDIO out, which settles the local-server credential question at the spec level instead of leaving it ambiguous.
The scope step-up and issuer-validation rules address concrete attack classes (over-scoped tokens, mix-up) rather than gesturing at security generally.

Cons / limitations / caveats

Draft status with no stated date: requirements (such as the planned iss SHOULD-to-MUST upgrade) can still change under the client.
Authorization being OPTIONAL means spec compliance alone never guarantees a server is authenticated; the client must still handle deliberately unauthenticated servers.
DCR deprecation is soft ("retained for backwards compatibility"), so the client must still decide how much legacy registration behavior to support.

Relevance to tai

Normative baseline for the tai MCP client's OAuth implementation: always send the RFC 8707 resource parameter, enforce audience discipline on every token, implement scope step-up with bounded retries, validate iss before code redemption, and prefer CIMD-first registration.

Changelog

Date	Change
2026-10-18	Initial dossier created.

4.3 KiB Raw Blame History