Doc / CSV / Python script (ZIP + PDF)Check that your remote MCP server handles auth the way the current MCP authorization spec (2026-07-28) expects: a 20-control checklist (discovery metadata, audience-bound token validation, per-tool scopes, no token passthrough, Origin/Host checks, SSRF limits, client registration), an evidence sheet, and mcp_auth_probe.py, a read-only probe of your own server's 401 challenge and protected-resource metadata. Server-side counterpart to the MCP Tool Access Review, which covers the client side.

What's inside
01_Remote_MCP_Auth_Checklist.md02_MCP_OAuth_Client_Safety.mdcontrols.csvmcp_auth_probe.pyUPDATE_2026-10-22.md14_Remote_MCP_Server_Auth_Kit.pdf: every document in one printable guide
Verify it works
python3 mcp_auth_probe.py --selftestprintsselftest ok(offline: a compliant server passes, a misconfigured one fails A1/A2/E1, a public server is marked CHECK).python3 mcp_auth_probe.py https://<your-server>/mcpagainst a server you own: it sends one unauthenticated initialize and reads the well-known metadata. Copy the results intocontrols.csv.- Walk sections B-F of
01_Remote_MCP_Auth_Checklist.mdwith your server code and logs; these need code review, not a probe. Record evidence per row. Python 3.9+, no installs.
Oct 2026 update (section 02, client side)
- [ ] Coding agents updated (OpenCode 1.18.33+).
- [ ] Remote MCP server list reviewed; untrusted servers removed.
- [ ] Controls C1 to C4 in controls.csv filled in.
Preview
First part of the main document, shown as-is:
Remote MCP Server Authorization Checklist
For teams exposing an MCP server over HTTP. Written against the MCP authorization specification (revision 2026-07-28) and OWASP AISVS chapter C10; read the originals for normative wording: - https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization - https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C10-MCP-Security.md
Mark each item Pass / Fail / N/A with evidence (request, config line or test name) in controls.csv.
A. Discovery
- A1. The server publishes OAuth 2.0 Protected Resource Metadata (RFC 9728) at
/.well-known/oauth-protected-resource, listing itsresourceidentifier and at least oneauthorization_serversentry. - A2. An unauthenticated request returns 401 with
WWW-Authenticate: Bearerthat includesresource_metadata(and the scope needed, where applicable). - A3. The authorization server publishes its metadata and advertises PKCE
S256.
B. Token validation (every request)
- B1. Signature, issuer, expiry and audience are checked; the audience must be this server's canonical resource URI, not a generic value like
api. - B2. Tokens issued for a different resource are rejected even if signed by the same issuer.
- B3. Missing scope returns 403
insufficient_scope. - B4. Validation uses a maintained library, not hand-rolled parsing.
C. Authorization per tool
- C1. Each tool declares required scopes;
tools/listreturns only tools the caller may use. - C2. Arguments are checked too (a token for "read own invoices" can't read another customer's).
- C3. Destructive or money-moving tools require a step-up or human approval.