Enable Programmatic Authentication for MCP Servers Without Browser Redirects

[calvertj]

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

[calvertj]

Just curious if any prototypes were needed to move this forward, and if so, which repo(s) are preferred.
Thanks.

[calvertj]

Oh, happy to make a PR for the modelcontextprotocol repo, would that be desired?

[travishaagen]

In cases like this, one could use the OAuth 2.0 client_credentials grant type.

[GregorySDTaylor]

In cases like this, one would use the OAuth 2.0 client_credentials grant type.

Client credentials are a great strategy for service accounts, but they don't represent the end user / resource owner. We believe that end-user-scoped tokens are especially important for AI agents because they are non-deterministic. Giving the AI client credentials increases the blast radius if they do something unexpected. We believe the first-party application flow is a great option for bringing in that concept of an end-user-scoped token in a non-browser context for a particular class of trusted AI applications.

[travishaagen]

I read the spec and I understand the use case of authenticating someone on a voice call with something out-of-band (txt msg, voice call, email, app notification, etc.).

The issue might be finding OAuth vendors or even open source products that support it.

One could use Device Authorization Flow for this use case.

I've also seen (hacky) solutions that use password grant-type (ROPG) to issue tokens for this kind of thing. Instead of credentials, you're actually sending metadata (e.g., from the voice server) as the username/password arguments, and your OAuth tenant intercepts it and "does the right thing". Once the whole process is complete, the token is issued.

[GregorySDTaylor]

I read the spec and I understand the use case of authenticating someone on a voice call with something out-of-band (txt msg, voice call, email, app notification, etc.).

I appreciate you doing the research! Our particular use-case is entirely in-band, no separate text / email / app. Out-of-band authentication would be a potential alternative to the First-Party App flow, especially with the Device Authorization flow you mentioned.

The issue might be finding OAuth vendors or even open source products that support it.

The first-party apps flow would likely be most appropriate for development teams that implement both a custom OAuth server and client application themselves.

[aaronpk]

The OAuth for First-Party Apps spec does seem like the correct solution for this. It is super important to only use it for first-party apps though, so I would not expect this to work for a random MCP client using the GitHub MCP server for example.

This came up in an IETF mailing list discussion as well, and I recommended the First-Party Apps draft there as well: https://mailarchive.ietf.org/arch/msg/agent2agent/jGRWPnbXhXiCUEMx1DKEGXO7tFc/

This is also somewhat related to the idea of server profiles: modelcontextprotocol/modelcontextprotocol#1004

[WhammyLeaf]

Any progress on this? Our company (and many others I imagine) are accessing MCP servers programmatically within layered processes. This works fine as long as the servers are not protected by oauth, but when they are then I don't any non hacky solution with the current MCP oauth spec.

[localden]

If this needs to be followed through on, seems like the most natural place is going to be auth extensions.

@aaronpk @calvertj thoughts?

[calvertj]

I think that would give us a path forward @localden, assuming we can contribute there?

[aaronpk]

I'd be happy to help give guidance on developing this as an extension

[GregorySDTaylor]

Thank you for the suggestion @localden and the guidance offer @aaronpk ! Our organization is at a decision point and I'll definitely reach out with a proposal / ask for assistance if we decide to go that route.