MCP Auth Conformance Lint

Lints every MCP server's OAuth setup against the MCP authorization spec and names the servers that accept the wrong tokens, advertise wildcard scopes, or skip per-client consent, for the platform engineer approving them.

Date: 2026-11-12 Theme: Tool Authorization (MCP / OAuth) Type: Web App Platform: MCP, OAuth Status: Prototype

What it is

A single-page linter. It reads each MCP server's protected resource metadata, its 401 challenge, its authorization server metadata, and a sample of decoded token claims, then runs 15 checks taken from the MCP authorization spec (draft revision, fetched 2026-11-12) and its security best practices page. The fleet table sorts the worst server to the top and the right-hand panel shows evidence, a fix, and the spec link for every finding.

Who it serves

A platform engineer who has to say yes or no to a new MCP server before agents are allowed to connect to it, and the security engineer who re-checks the ones already in production.

The agent security pain it addresses

Most MCP security failures on the authorization side are checkable from config. The spec says an MCP server MUST accept only tokens issued for it (audience check), MUST NOT pass the client's token to an upstream API, and a proxy that uses a static client ID with dynamic registration MUST get per-client consent. The best practices page lists wildcard and omnibus scopes (*, all, full-access) as a common mistake, and says SSRF risk comes from discovery URLs that point at private or link-local addresses. None of that is visible in a tool-approval ticket. Today a reviewer reads the vendor's README, or nobody reads anything.

The agent angle: an agent that holds a wildcard-scoped token and reads attacker-influenced content (see OWASP LLM01) turns every tool on that server into a possible action. A server that skips the audience check lets a token minted for one server work on another, so a stolen token from a low-risk server reaches a high-risk one. These are token-handling bugs in the server, not agent behaviour, and an agent platform team is usually the only party placed to check them across the fleet.

This tool is not the sibling IAM stream's grant-versus-usage trimming. It checks whether the server is built to the spec, not whether an identity uses what it holds.

How it works

On load the page lints the 11 sample servers and opens the worst one. A red banner names it: CRM gateway MCP (OAuth proxy) has no owner and fails 11 checks. Seeded problems on that server:

• it forwards the client's token to its upstream API (R01, critical)
• it is a proxy with a static client ID, DCR and no per-client consent (R02, critical)
• one agent's token has an audience for a different server, so this server accepted it or a sibling would (R03)
• scopes_supported contains * and crm:admin, tokens live 24 hours, one token arrived in the query string, and offline_access is advertised

Other servers carry single faults: a file-share server whose AS metadata lacks code_challenge_methods_supported, a finance server whose authorization server is a plain-HTTP private address. Seven servers are clean so the table is not all red. Filters cover severity, high-or-critical only, and free text across server, owner and agent names. Export writes the findings as JSON.

What's in this folder

• requirements.md: functional requirements and test cases
• index.html: the app; the sample data is inlined so it runs from file://
• style.css, script.js: layout and the rule engine (the rules are the RULES array at the top of script.js)
• sample-data.json: 11 fictional servers on example.com, same content as the inlined copy
• cover-image.png, metadata.md

How to run / read it

Open index.html in any modern browser. No build, no network, no keys.

Estimated impact

It replaces a manual read of three specs per server with a checklist that runs in seconds, and it makes the fleet comparable. I have not measured review time. The credible claim is narrower: the checks it covers (audience, passthrough, consent, wildcard scopes, PKCE advertisement, HTTPS and private-address discovery URLs) are the ones the spec marks MUST, so a server failing them is non-conforming, whatever else is true of it. It does not test runtime behaviour. A server can publish clean metadata and still skip the audience check; R03 catches that only from sampled tokens.

Adapters and scale

Inputs: GET /.well-known/oauth-protected-resource (RFC 9728) and the authorization server's RFC 8414 or OpenID Connect metadata per server; the WWW-Authenticate header from an unauthenticated probe; decoded token claims (aud, scope) from gateway or authorization server logs, delivered as OpenTelemetry or OCSF events; an agent-to-server map from the inventory. Each server is one static fetch plus a handful of log rows, so 100+ servers lint in a single pass and can run on a schedule, with diffs between runs flagged. The prototype ships no live fetchers, only the normalized shape they would fill (assumption).

Assumptions and limits: rule R04 treats :admin suffixes as omnibus, which is this tool's judgment, not spec text. The 3600-second token lifetime in R10 is a configurable policy value; the spec only says short-lived. All rules are structurally illustrative and need validating before they gate anything.

Sources

1. MCP authorization spec, draft: https://modelcontextprotocol.io/specification/draft/basic/authorization
2. MCP authorization security considerations, draft: https://modelcontextprotocol.io/specification/draft/basic/authorization/security-considerations
3. MCP security best practices, draft: https://modelcontextprotocol.io/specification/draft/basic/security_best_practices
4. RFC 9728, OAuth 2.0 Protected Resource Metadata: https://datatracker.ietf.org/doc/html/rfc9728
5. Search results on 2026 MCP OAuth practitioner write-ups (a vendor-sourced article on resource indicators and token audience, dated 2026-06-16, and others; I read search snippets, not the full pages): https://nhimg.org/articles/oauth-resource-indicators-harden-mcp-server-token-audience-binding/