OAuth: accept Client ID Metadata Documents (MCP 2026-07-28 client registration)

Open
  • Is something wrong?
#2,007 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
api, authentication, security

Research direction

Start by examining the OAuth server implementation, internal/egressguard, and the go-sdk auth/oauthex packages at v1.8.0 to identify existing fetch and validation support. Read docs/auth/oauth-server.md and the authorization metadata paths, then use the stated acceptance cases and local MCP client flow to verify CIMD, DCR compatibility, controls, auditing, and updated llms.txt and llms-full.txt.

Written by the indexing model from the issue text.

Description

deferred enhancement

Problem

MCP 2026-07-28 makes Client ID Metadata Documents (CIMD) the client registration mechanism. A client identifies itself with an HTTPS URL as its client_id, and the authorization server fetches the client's metadata from that URL. Dynamic Client Registration (DCR) remains for backward compatibility and is slated for removal in a later revision.

The platform's OAuth server supports pre-registered clients and DCR only (docs/auth/oauth-server.md: oauth.dcr.enabled, POST /oauth/register). Nothing in the OAuth server or its docs handles a URL-shaped client_id. A client that only does CIMD cannot authorize against the platform, and an enterprise security review asking "do you support CIMD" gets "no".

Required behavior

  • /oauth/authorize and /oauth/token accept an HTTPS URL as client_id, fetch the metadata document it names, and validate it:
    • the document's client_id equals the URL;
    • redirect_uri is one the document lists;
    • token_endpoint_auth_method is supported.
  • The fetch is SSRF-guarded (internal/egressguard) and size-, time- and cache-bounded, honoring the document's cache headers.
  • Authorization server metadata advertises CIMD support (client_id_metadata_document_supported).
  • Operator control: a setting enabling CIMD (default on), and an optional allow/deny list of client-ID hosts for deployments that admit only known clients.
  • The consent screen shows the client's name and logo from the document, and its host.
  • DCR keeps working unchanged. The docs say CIMD is the preferred path and DCR the legacy one.
  • Audit: an authorization by a CIMD client records the client_id URL.

Acceptance

  • An MCP client using CIMD (a test client serving its document from the local stack) completes authorization code + PKCE against the dev stack and calls a tool.
  • A document whose client_id does not match its URL, a redirect_uri not listed, a private-address URL, and an oversized document are each refused with a reason.
  • A host outside the allow list is refused when one is configured.
  • docs/auth/oauth-server.md has a CIMD section; llms.txt and llms-full.txt are updated.

Before building: check how much of the fetch and validation go-sdk's auth/oauthex packages (v1.8.0) already provide, and use them rather than writing a second implementation.

Dominant language
Go
Stars
10
Forks
2
Avg merge
1h 38m
Merged PRs (30d)
84

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from txn2/mcp-data-platform

All issues in txn2/mcp-data-platform

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.