Enable Programmatic Authentication for MCP Servers Without Browser Redirects

No implementation files, tests, or entry points are named. Start by reading the linked MCP Authorization Specification, RFC8414, and OAuth 2.0 for First-Party Applications draft; done would require identifying the target repository and agreeing how the optional metadata endpoint and challenge flow should be specified or implemented.

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:

Client -> Redirect to Authorization Endpoint -> Browser -> Callback

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):

{
  "issuer": "https://mcp.example.com",
  "authorization_endpoint": "https://mcp.example.com/authorize",
  "authorization_challenge_endpoint": "https://mcp.example.com/authorize/challenge",  // NEW
  "token_endpoint": "https://mcp.example.com/token",
  // ... other standard fields
}

2. When authorization_challenge_endpoint 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