Track support for the MCP OAuth Client Credentials extension

[dbernheisel]

Tracking issue for the OAuth Client Credentials auth extension for MCP. This issue is for tracking the gap only — not proposing an implementation.

• Overview: https://modelcontextprotocol.io/extensions/auth/oauth-client-credentials
• Spec (draft): https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/draft/oauth-client-credentials.mdx
• Repo: https://github.com/modelcontextprotocol/ext-auth

What this extension adds

OAuth 2.0 client-credentials flow for MCP, intended for non-interactive clients (daemons, long-running workers, automated systems) that need to authenticate to an MCP server without a user-driven authorization step. It complements the user-delegated OAuth flow that the core MCP authorization spec already covers.

Key spec points:

• Two client authentication methods on the token endpoint:
  • JWT Bearer Assertion (recommended) — RFC 7523 §2.2 with parameters grant_type=client_credentials, client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer, client_assertion=<JWT>. Client identity comes from the JWT's sub claim; the client_id form parameter is omitted.
  • Client secret — OAuth 2.1 §2.4.1 with grant_type=client_credentials, client_id, client_secret.
• Authorization-server discovery metadata that must be published:
  • token_endpoint_auth_methods_supported must include "private_key_jwt" and/or "client_secret_basic".
  • token_endpoint_auth_signing_alg_values_supported for JWT auth.
  • Both OAuth 2.0 and OpenID Connect discovery endpoints are consulted.
• Token lifetime / refresh — client-credentials tokens are typically short-lived; clients are expected to refresh proactively.
• Security — client secrets are long-lived credentials; rotation and leakage handling are explicitly called out.

Current state in Phantom

Phantom intentionally does not implement authentication itself. The README directs users to bring their own OAuth provider (Oidcc, Boruta, ExOauth2Provider) and to handle auth in the connect/2 callback (lib/phantom/router.ex). As a result there is:

• No first-class affordance for advertising or recognizing client-credentials flow at the MCP server boundary.
• No helpers or documentation pattern for accepting JWT bearer assertions vs. client_secret_basic from non-interactive callers in connect/2.
• No guidance on what token_endpoint_auth_methods_supported / token_endpoint_auth_signing_alg_values_supported a Phantom-fronted server should expose at its discovery endpoint when paired with a user's chosen OAuth provider.
• No documented pattern for c:Phantom.Router.connect/2 distinguishing user-delegated principals from machine principals, which matters for allow_tools/allow_resource_templates decisions.

Why this matters

Daemon-style and server-to-server MCP integrations (CI jobs, scheduled syncs, internal services) need a non-interactive auth path. Without first-class recognition of this extension, every Phantom user has to reinvent how their OAuth library maps onto the MCP client-credentials profile, including the discovery metadata they advertise.

Out of scope for this issue

Design and implementation. This issue exists to make the gap visible and link to the spec.