Every new protocol introduces its own complexities. When a new protocol shows up, the first question to ask is whether it is truly necessary. So, let’s ask that question about the model context protocol (MCP).
The current wave of agentic apps, sparked by tools like ChatGPT, are powered by large language models (LLMs) that excel at tasks like summarization, content creation, and image processing but come with fundamental limitations. Namely:
- No access to real-time data
- No access to private data
- No ability to execute tools
MCP addresses the above limitations by acting as a universal protocol that connects agentic apps to real-world data and tools. But it’s fair to ask, why introduce a new protocol when we already have secure and high-performing APIs?
The short answer is that, while today’s powerful APIs can be connected to agentic apps, there’s a challenge. These APIs vary widely, e.g. REST, GraphQL, gRPC, using HTTP, WebSockets, Pub/Sub. Their auth mechanisms differ too, e.g. API keys, OAuth2. That means each integration is bespoke. Developers must read docs, build flows, and wire up APIs one by one.
WSO2
This static integration model is proven but doesn’t match the dynamic nature of agentic apps. That’s where MCP comes in. MCP defines clear client-server roles, a standard protocol format, and a life cycle, essentially becoming the universal connector between LLMs and external systems. So you can think of MCP as the USB-C in the API world.
How MCP works
MCP defines three core roles—a host, a client, and a server:
- Host: Agentic applications that manage client life cycles and enforce security.
- Client: Lightweight connectors within hosts that establish a 1:1 session with an MCP server.
- Server: Programs that connect MCP clients to data sources and tools, either locally or remotely.
WSO2
Each role provides a set of features. MCP servers expose resources (contextual data like calendar events), prompts (structured templates that guide user input to improve LLM output), and tools (executable functions). MCP clients connect to MCP servers to request data, execute tools, and orchestrate agents.
MCP uses JSON-RPC, a lightweight, structured protocol for requests and responses, and defines two standard transport mechanisms for client-server communication, standard input and output (STDIO) and streamable HTTP.
Securing a local MCP server
When the MCP server runs locally, the STDIO transport should be used. In practice, this means the agentic app launches the MCP server as a sub-process and communicates through its standard input and output streams. Because this communication stays entirely within the local system, it’s inherently secure, and the MCP auth spec doesn’t require any additional security.
WSO2
However, when an MCP server communicates with back-end APIs, typically over the internet, security becomes a top priority, but falls outside the scope of the MCP auth specification. Nevertheless, there is still no need for new mechanisms; existing API security practices suffice. Common approaches include:
- Long-lived tokens: API keys and tokens, valid for days or months, are obtained via out-of-band channels and configured in the MCP server.
- Short-lived tokens: With lifespans under an hour, short-lived tokens can’t be set manually. Instead, the MCP server must dynamically request them at run time with user approval. OAuth2 access tokens and JWTs are typical examples.
Securing a remote MCP server
An MCP client connects to a remote MCP server via HTTP by initiating a request to its endpoint URL. As specified by the MCP auth spec, this endpoint must be OAuth 2.1-protected, requiring the client to present a valid access token.
WSO2
The MCP auth spec outlines a token acquisition process designed to support dynamic, agentic integrations. These interactions include the following steps.
WSO2
Server metadata discovery
Once the MCP server URL is provided as a configuration parameter, the client constructs a server metadata endpoint by removing any path components and appending a /well-known/oauth-authorization-server path. The client then retrieves a JSON-formatted server metadata document from this endpoint. Both the endpoint and the document must comply with the OAuth 2.0 Authorization Server Metadata specification. This metadata helps the client discover the following information required during the next steps:
- Registration endpoint
- Authorization and token endpoints
- Supported grant types and scopes
Deriving the server metadata endpoint from the MCP server URL was meant to let clients operate with a single configuration parameter. However, this tightly couples the authorization and resource server roles, limiting the use of existing OAuth 2.0 infrastructure and purpose-built identity solutions. To address this, the upcoming MCP auth spec replaces this mechanism with the OAuth 2.0 Protected Resource Metadata specification.
Client registration
Based on the information retrieved from the server metadata document, the client application sends a registration request to the client registration endpoint. The MCP auth specification adopts the OAuth 2.0 Dynamic Client Registration (DCR) protocol to register the client as an OAuth 2.1 client. In the DCR response, the client application receives a client_id and, for confidential clients, a client_secret. Both are required for the next step.
While DCR is widely adopted, opinions vary on open registration, and the spec itself allows protecting the registration endpoint with OAuth 2.0. Again, to support single-parameter configuration, the MCP auth spec recommends open registration. It remains to be seen how this will evolve.
Access token retrieval
At this stage, the client has everything needed to request an access token. Depending on the use case, one of the following OAuth 2.1 grant types is used:
- Client Credentials: If the client application is accessing the MCP server directly, it uses the Client Credentials grant with the
client_idandclient_secretobtained during registration, along with the token endpoint and scopes discovered from the server metadata. - Authorization Code: If the client accesses the MCP server on behalf of an end user, it uses the Authorization Code grant. This flow requires the
client_idandclient_secretfrom registration and the authorization endpoint, token endpoint, and scopes from the server metadata. Additionally, as required by OAuth 2.1, the client must use Proof Key for Code Exchange (PKCE) to enhance security.
WSO2
If everything goes well, the client application obtains a valid access token and can initiate a connection request to the MCP server URL, passing the token via the Authorization HTTP header. The MCP server then validates the token and establishes the connection if it’s valid.
Ultimately, this security flow aligns with typical OAuth-based API security flows, except for the initial step of deriving the server metadata URL from the MCP server URL.
Sagara Gunathunga is director of solutions architecture at WSO2.
—
Generative AI Insights provides a venue for technology leaders to explore and discuss the challenges and opportunities of generative artificial intelligence. The selection is wide-ranging, from technology deep dives to case studies to expert opinion, but also subjective, based on our judgment of which topics and treatments will best serve InfoWorld’s technically sophisticated audience. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Contact doug_dineley@foundryco.com.
