Last 12 weeks · 2 commits
5 of 6 standards met
Is your feature request related to a problem? Please describe. The current Authorization Spec draft focuses many details on a client that performs the login itself with Authorization Code Flow + PKCE. I see use cases where the client would not interact with the user, and instead the host application receives an access token from some other application that has been granted access to the host app on behalf of a user. When this happens, it seems Token Exchange is the proper method to obtain a new access token meant for the MCP Server. I wonder if there needs to be some way for a client to know the expected value of the MCP Server's audience claim. I'd like to open discussion surrounding this use case. Describe the solution you'd like I wonder if there could be a section in the Authorization spec dedicated to this use case. Evidently the token validation in this case would need to be performed by the Host application instead of the MCP Client (which I'm not sure is in the scope of this spec?). However, the token exchange is something that I believe should fall to the MCP Client if in other cases the MCP Client is responsible for handling the login. Given this affects the implementation of an MCP Client, I believe this belongs in the main authorization spec. Describe alternatives you've considered If this is perhaps not meant for the main authorization spec, I feel this is a common enough pattern at least worth a mention in the security-best-practices doc. Additional context This issue is semi-related to modelcontextprotocol/modelcontextprotocol#214 but is a slightly different (maybe broader) use case. Also having been watching the open PR modelcontextprotocol/modelcontextprotocol#408 possibly there should be some discussion of token exchange by the server to downstream tool, but perhaps that use case discussion can belong in another issue.
Repository: modelcontextprotocol/ext-auth. Description: Extensions to authorization Stars: 61, Forks: 19. Primary language: MDX. Languages: MDX (100%). License: MIT. Open PRs: 7, open issues: 6. Last activity: 2w ago. Community health: 100%. Top contributors: D-McAdams, aaronpk, pcarleton, localden, koic.
Problem Definition Concrete Implementation Challenge: We are building a voice-based healthcare agent that needs to authenticate patients over phone calls. The current MCP OAuth specification requires browser-based redirects, which is impossible in a voice channel. Validation: This affects any MCP implementation where: Users interact through voice (IVR systems, voice assistants) CLI tools need authentication without launching browsers Embedded devices without browser capabilities Current Blocker MCP specification mandates OAuth 2.1 with browser redirects: This flow cannot work when: 1. No browser is available (phone calls) 2. Browser interruption breaks user experience (CLI tools) Minimal Proposed Change Allow MCP servers to optionally support programmatic authentication by adopting the OAuth 2.0 for First-Party Applications specification: 1. Add an optional field to Authorization Server Metadata (RFC8414): 2. When is present, clients can use the challenge/response flow as defined in the First-Party Apps draft. Why This Is Minimal 1. Single metadata addition: Just one optional endpoint in server metadata 2. Existing specification: Follows an established IETF draft rather than inventing new patterns 3. Backwards compatible: Only active when server advertises the endpoint 4. No protocol changes: Still uses authorization codes and standard token exchange Security Considerations Per the First-Party Apps specification: MUST only be used by first-party applications Authorization servers SHOULD restrict this endpoint to specific trusted client IDs All security requirements from Section 9 of the draft apply Use Case Example A voice agent could authenticate callers using knowledge-based authentication: Collect identity information (name, DOB, SSN last 4) POST to the challenge endpoint Receive authorization code Exchange for access token using standard flow Access MCP resources with the token Alternative Considered We considered using custom extensions, but that would fragment the ecosystem. Adopting an existing IETF draft enables broad use cases while maintaining compatibility. Prototype tell me which repo(s), if any, you want a protoytype created in, and I can make a PR. References OAuth 2.0 for First-Party Applications Draft MCP Authorization Specification OAuth 2.0 Authorization Server Metadata (RFC8414) Co authored by gregorySDTaylor and claude-sonnet-4
Summary Defines an optional extension for cryptographic server identity and tool attestation in MCP Ed25519 key pairs for server identity, self/publisher/DNS attestation types, tool definition signing via , challenge-response verification, and key revocation Complements existing auth extensions (Client Credentials, Enterprise-Managed Authorization) by addressing server-to-client identity verification Motivation MCP has no mechanism for clients to verify server identity or detect tool definition tampering. The OWASP MCP Top 10 identifies related risks: MCP03 — Tool Poisoning (tool definition tampering) MCP04 — Supply Chain Attacks (no provenance chain) MCP07 — Insufficient Authentication (no mutual auth) MCP09 — Shadow MCP Servers (server impersonation) Existing auth extensions solve client-to-server authorization. This extension solves the complementary problem: server-to-client identity. Context This was originally submitted as SEP-2267 to the core spec repository. Per maintainer guidance from @localden, this extension belongs in rather than the core spec. The document has been reformatted to follow the ext-auth extension conventions (MDX format, numbered sections, parameter tables, RFC keyword styling). What's Included — Full extension specification Extension capabilities: 1. Server Identity — Ed25519 key pairs in JWK format, identity metadata 2. Attestation Types — Self (TOFU/key pinning), publisher (third-party signing), DNS (domain binding) 3. Tool Attestation — Cryptographic signatures over tool definitions via 4. Challenge-Response — and JSON-RPC methods 5. Key Revocation — Revocation attestations and key rotation Backward Compatibility All new fields and methods are additive. Servers that do not implement this extension are unaffected. Clients that do not support it ignore the identity metadata. Existing OAuth mechanisms continue to work unchanged. References OWASP MCP Top 10 Invariant Labs: MCP Tool Poisoning Attacks RFC 7517: JSON Web Key RFC 8785: JSON Canonicalization Scheme RFC 8032: EdDSA