We’re excited to partner with Cloudflare to help make every application agent-accessible with today’s launch of Remote MCP Authorization in Stytch Connected Apps. With this launch, developers can easily add authorization to Remote MCP Servers built on Cloudflare Workers, and any other frameworks supporting MCP Servers.

Bringing MCP to the Internet

Model Context Protocol (MCP) is an open standard designed by Anthropic that defines how AI agents (the “Client”) can communicate with servers and discover their capabilities. Servers provide functionality that the agent’s underlying LLM doesn’t natively support—enabling the agent to interact with third-party applications and perform complex workflows without requiring bespoke, hardcoded integrations for each app.

Originally MCP servers could only run locally on your machine, but recent updates to the specification have defined support for Remote MCP, bringing MCP to the internet and making it possible for every web application to offer agents access in a way that is broadly accessible and easy for end users to use.

However, there are a number of challenges facing developers who want to build remote MCP servers:

• Support for remote transport that supports bi-directional, real-time communication
• Backwards compatibility with MCP clients designed for local MCP servers
• State management to support multi-step workflows
• Registering new MCP clients dynamically
• Secure, tightly-scoped access controls for what MCP Clients can do on the user’s behalf

Cloudflare’s recent launch of their workers-mcp package offers developers out-of-the-box support for the core remote transport and state management challenges, as well as a foundational abstraction layer for adding in Client authorization via OAuth, solving most of the issues mentioned above.

While Cloudflare provides the foundation for Remote MCP servers, there are still several key challenges for handling Remote MCP authorization, namely in secure and robust authorization for these AI agents. With today’s launch, Stytch Connected Apps solves this last problem by enabling Remote MCP authorization via OAuth.

Agent authorization via OAuth 2.0

Bringing MCP to the internet requires robust MCP client authorization. At Stytch we’ve advocated using OAuth 2.0 for agent authorization and are excited to see this approach incorporated into last month’s revision to the MCP specification for Remote MCP.

OAuth 2.0 offers a well established protocol for authorizing clients to act on an end user’s behalf within an application, and its sister protocol OpenID Connect (OIDC) offers an established pattern for communicating the identity information of that end user. As such, OAuth is the standard being used to allow AI agents to authenticate with APIs. Cloudflare offers basic OAuth in their Getting Started guide as a proof of concept, but recommends more robust implementations, like Stytch, for production-level solutions that maintain core security features.

"If you want to allow people to grant an MCP Server permission to read or write data on their account, you’re going to need an OAuth provider. Stytch makes OAuth easy and has worked perfectly with the MCP Server support we’ve built into the Cloudflare Agents SDK. We continue to be amazed by just how quickly companies have been able to get up and running in production with remote MCP servers, and we’re excited to see what developers continue build with Stytch and Cloudflare together."

– Brendan Irvine-Broque, Director of Product, Cloudflare

While OAuth 2.0 specifications have been the standard for enabling 3rd party integrations that require end user consent and scoped permissions for over a decade, becoming a fully-fledged identity provider is a significant, ongoing lift. Identity standards are complex and ever-changing with over 30 published OAuth RFCs and a dozen active drafts. Developers not only need to think about implementing the specifications, they also need to think about everything the specifications don't cover, including:

• Management of 3rd party clients
• Application-specific scopes and permissions
• End user and IT admin management of granted consent
• Revoking access on end user deactivation or role change
• Securing powerful credentials like private keys used to sign Access and ID tokens
• Responding to new and novel attacks

As a result, this was typically only worthwhile for large companies with enough reach to incentivize 3rd party developers to build integrations for their platform. Remote MCP changes this.

Autonomous client registration

The real magic of Remote MCP is allowing clients and servers to communicate without human interaction.

In traditional OAuth 2.0, client registration is a manual setup process where the 3rd party developer creates a client in a GUI, provides their redirect URIs, and receives a Client ID and secret that can then be used to authenticate the client during the authorization flow.

In order to allow clients and servers to communicate without this manual setup process, the MCP specification encourages servers to implement the Dynamic Client Registration (DCR) and Authorization Server Metadata standards. These protocols allow each MCP client to autonomously discover information about the MCP server, self-register, and report their redirect URIs. In turn, this means MCP client developers don't need to maintain relationships with every MCP server that exists – democratizing the type of tools that can be leveraged by AI agents in complex workflows

While DCR is part of the OAuth 2.0 specification, adoption of DCR has been mostly non-existent for third-party applications – since without a smart client that can learn how to communicate with the server, there is very little value to removing the initial setup step.

As a result, there are a lot of open questions to figure out for developers who want to add DCR to their MCP server, including:

• How should I manage dynamically created clients' lifecycles? How can I understand what MCP Clients are accessing my application?
• How can IT Admins control access to dynamically created clients within their organization?
• How can Dynamic Client Registration be implemented securely, avoiding common OAuth security issues like Client Impersonation?

Stytch addresses these concerns before they become problems. Using Stytch as your auth provider to handle OAuth for MCP, you get to take advantage of the already robust infrastructure, security, administrative tools, and built-in future-proofing. Moreover, Stytch Connected Apps goes beyond the minimum spec to let MCP be production-ready, instead of proof-of-concept software.

MCP servers as identity providers vs relying parties

At a high level, there are two key flows for building authorization into Remote MCP servers:

1. MCP servers that function as the Identity Provider in the OAuth exchange
2. MCP servers that function as a Relying Party in the OAuth exchange

Stytch provides a toolkit to create identity providers, which allows us to support either use case. If your MCP Server is more of a standalone application, Stytch enables you to turn the MCP server itself into an identity provider. If you want to expose your existing application to an MCP server, Stytch allows your application to serve as the identity provider – enabling end user authentication and client authorization across both your normal web app and your MCP server.

Regardless of your approach, Stytch Connected Apps provides everything you need to grant secure, well managed access to AI agents on behalf of your users, including:

• Core OAuth 2.1 specification
• Dynamic Client Registration
• Authorization Server Metadata
• Custom Scopes based on Resources/Actions granted as permissions to end users
• Client Management with deduplication on ClientID for DCR Clients
• End user and IT Admin management of granted consent
• Organization controls on whether to allow DCR client authorization

Curious about how this might look in action? We’ve built a sample application showcasing how Stytch handles member, tenant, and client identity on a traditional full-stack application on a MCP Server. Or read our docs to build it yourself.

Shaping the agentic future

While the addition of Authorization to the Remote MCP specification is exciting, there are still gaps. For example, defining a clear pattern for discovering and requesting custom scopes, in order to ensure that MCP Clients can identify what access they need to perform the task at hand and limit their access request to those permissions.

Today’s launch of Stytch Connected Apps for MCP servers addresses this. It gives your apps and agents the power to authenticate with one another using best-in-class security practices and infrastructure. We’ll continue to help shape how authentication and authorization can and should behave for Remote MCP, and are excited to partner closely with Cloudflare to understand the evolving needs and use cases for Remote MCP Servers. Our engineers are even hard at work directly contributing to the open source specifications, establishing Stytch as a leader in the space.

Curious about how MCP fits into your product, or want to chat about your ideas? Continue the discussion with us by contacting us directly to get a demo. We’re always looking for interesting and unique use cases to make the Agentic Future a reality.