Authorization Charter

​

Group Type

Interest Group

​

Mission Statement

The Authorization Interest Group provides a venue for MCP implementers, identity-provider vendors, and security practitioners to surface real-world authorization challenges encountered when deploying MCP clients and servers. The group gathers use cases, documents gaps in the current OAuth 2.1–based authorization specification, and incubates validated problems until they are scoped well enough to propose a focused Working Group via the standard group-creation process to drive the corresponding SEPs.

​

Scope

​

In Scope

• Deployment experience reports: how implementers have integrated the current authorization spec (OAuth 2.1, RFC 9728 Protected Resource Metadata, RFC 7591 Dynamic Client Registration, Client ID Metadata Documents) with real authorization servers, and where it falls short
• Enterprise identity integration: requirements and friction points when connecting MCP servers to enterprise IdPs (Okta, Entra ID, Ping, Keycloak, etc.), including SSO, tenant isolation, and admin consent flows
• Delegated and agentic access: use cases for on-behalf-of token exchange, downstream resource access, audience restriction, and consent when an MCP client acts through chains of agents or tools
• Scope and permission granularity: whether and how MCP servers should advertise fine-grained scopes (per-tool, per-resource) and how clients should request and present them
• Credentials for non-HTTP transports: patterns for stdio, WebSocket, and future transports where the HTTP authorization spec does not directly apply
• Client identity and registration: operator experience with Dynamic Client Registration, Client ID Metadata Documents, software statements, and pre-registered clients
• Threat modelling input: cataloguing authorization-related attack surfaces (token confusion, confused-deputy, audience mismatch, redirect handling) to inform Security Best Practices documentation
• Proposing Working Groups: once a problem is validated and scoped, the IG submits a Working Group creation proposal via the standard #wg-ig-group-creation process; approval remains with community moderators and core maintainers
• Problem statements and requirements: use-case catalogues and recommendations published to GitHub Discussions for consumption by SEP authors and Working Groups

​

Out of Scope

• Authentication of end users to MCP clients: how a host application authenticates its own users is a host concern, not a protocol concern
• Transport security (TLS, mTLS, certificate handling): belongs to the Transports WG
• Server identity, provenance, and trust signalling: belongs to the Server Card / Registry efforts
• End-user product configuration walk-throughs: the IG discusses patterns, not step-by-step setup for individual IdP products. Vendor-reported constraints on what an authorization server can or cannot implement are in scope as deployment experience
• Competitively sensitive or non-public business information, per the MCP Antitrust Policy

​

Related Groups

• Transports WG: authorization is currently specified at the HTTP transport level; changes to transports affect where credentials are carried
• Agents WG: delegated/on-behalf-of access and consent for multi-agent chains overlap heavily with agentic use cases
• Server Card WG / Registry: client and server identity, discovery metadata, and trust establishment intersect with how authorization servers and resource servers are located and verified
• SDK Maintainers: SDKs ship the auth client implementations; IG findings should inform cross-SDK auth ergonomics

​

Leadership

​

Membership

Open to anyone; no formal membership or approval step is required to join the channel, attend calls, or contribute. Join the #auth-ig channel on the MCP Contributors Discord or open a thread in the Authorization category of GitHub Discussions. If your topic clearly matches one of the Working Groups in the table below, you can post directly in that WG’s channel. Calls are open and attendance is optional — async participation via Discord and GitHub is equally valued.

​

Operations

Discord: #auth-ig

​

Working Group Incubation

A topic graduates to a Working Group proposal when it has a written problem statement in GitHub Discussions and rough consensus on a bi-weekly call (recorded in published notes). A facilitator then files the standard WG creation template in #wg-ig-group-creation, citing that discussion. The IG’s role ends at the proposal; approval remains with community moderators and core maintainers.

​

Deliverables & Success Metrics

The IG incubates problems until they are well-scoped, then proposes focused Working Groups to drive specific SEPs. Each spawned WG maintains its own charter; this list is a directory, not a substitute. The IG stewards modelcontextprotocol/ext-auth, where individual WGs land authorization extension specifications via PR.

​

Changelog