PostHog / PostHog/posthog

chore(oauth): MCP-client compatibility matrix for scopes_supported absence and 401 challenges

Open
#57,528 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
39.9k
Forks
3.4k
Avg merge
6h 51m
Merged PRs (30d)
232

Description

Context

Before we can drop `scopes_supported` from MCP's RFC 9728 protected-resource metadata response (#57530), we need to know how each MCP client behaves when the field is absent or partial. RFC 9728 § 7.2 says the field is RECOMMENDED, not required, but the MCP spec is silent on what clients MUST do when it's absent. Claude Code has a history of RFC 9728 non-compliance.

Without empirical data, dropping the field is wishful thinking. With it, we know exactly which user populations the structural cleanup helps and which need a different solution.

Test matrix

For each client, install the PostHog MCP server and observe behavior under three configurations:

Config What to vary
A. Full `scopes_supported` published Baseline — confirm current behavior
B. Truncated `scopes_supported` (1-2 scopes) What does client request at /authorize? Union? Just published list?
C. `scopes_supported` field absent Does client request empty scope (gets `openid` default)? Pre-fab union? Crash?

For each (client, config) pair, capture:

  • Scopes actually passed to /authorize
  • Whether OAuth flow completes
  • Whether tools render correctly
  • Whether subsequent tool calls work
  • Any client-side error messages
  • Network trace if non-obvious

Clients to cover

  • Claude Code (CLI)
  • Claude Desktop
  • mcp-remote (npm shim, used by many other clients)
  • Cursor
  • Cline
  • VS Code MCP
  • ChatGPT connector

Other validations

  • Verify Cloudflare doesn't strip `WWW-Authenticate` headers in the public path (curl test against prod endpoint with a deliberately invalid token)
  • Pull MCP server access logs: distinct `User-Agent` values hitting `/.well-known/oauth-protected-resource` over last 30 days. Sets the rollout risk for #57530.

Output

Single results doc (could be a notebook, GitHub gist, or comment on this issue) with the test matrix filled in. Used as input to #57530's rollout decision.

Tracking

Parent: #57524
Blocks: #57530
Project: https://github.com/orgs/PostHog/projects/194

Contributor guide

Open the contributing guide

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.

Research direction

Start at the /.well-known/oauth-protected-resource endpoint and /authorize flow, using the PostHog MCP server with each listed client. Run configurations A–C, capture the requested scopes, flow and tool behavior, and test the public endpoint's WWW-Authenticate header with an invalid token. Done means a completed results document, Cloudflare validation, and access-log User-Agent findings.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
api, authentication, security
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.