The Model Context Protocol (MCP) is an open standard that bridges LLM models with external data, API, and services. But how do we enable this kind of connectivity without compromising on security or proper authentication best practices?

In this post, we’ll cover how authentication works in MCP, the responsibilities of each component, and the key piece that often goes unnoticed—the authorization server.

What is MCP?

If you’ve been following the AI agent space, you’ve probably heard of MCP already—but here’s a quick refresher.

MCP (Model Context Protocol) is an open standard developed by Anthropic that defines a consistent, structured interface between AI agents and external services like APIs, databases, and third-party tools. Instead of building bespoke integrations or writing custom glue code, developers can implement the MCP interface in a standardized way to expose external systems and tools to AI agents.

In MCP, there are three core roles:

1. MCP clients live inside AI agents. They're responsible for making requests to services via transport protocols like stdio or SSE.
2. MCP servers act as integration layers that expose tools and actions to MCP clients. These servers wrap external APIs or systems and translate incoming MCP calls into backend logic.
3. Third-party services are the external APIs or systems (e.g., GitHub, Notion, Google Calendar) that the MCP Server connects to. The server translates MCP requests into calls to these services.

An MCP client may request something like createToDo, and the MCP server fulfills the request by calling the appropriate third-party API.

But how do these MCP clients, MCP servers, and third-party services securely connect with each other?

How MCP authentication works

Authentication in the Model Context Protocol builds on a well-established and secure foundation: OAuth. This lets users log in, review requested permissions, and explicitly authorize agents to act on their behalf—all using familiar patterns from modern federated authentication and delegated authorization.

Here’s what a simplified OAuth flow might look like in the context of MCP:

1. MCP client initiates a request to an MCP server.
2. Server responds with a 401 Unauthorized and a redirect link to login to an OAuth provider.
3. User logs in to the OAuth provider, views a consent screen, and grants requested scopes.
4. Server returns an auth code to the client.
5. MCP Client exchanges the code for access + refresh tokens.
6. OAuth tokens are used for all subsequent MCP client requests.
7. MCP server calls the third-party service.

And within that flow, the latest MCP spec formalizes expectations around how OAuth authorization will operate with MCP servers. Specifically, it mandates or strongly recommends implementing:

• PKCE: All MCP auth flows must adhere to the OAuth 2.1 specification, including mandatory use of PKCE to protect authorization code exchanges.
• Authorization Server Metadata: MCP servers should expose standard metadata (per RFC 8414) to help clients discover supported endpoints and capabilities automatically.
• Dynamic Client Registration: MCP servers should support dynamic client registration to simplify the process of onboarding new clients and agents.

At this point, you might wonder: who is responsible for handling all of these OAuth flows? Which component is acting as the OAuth identity provider, relying party, the resource server, or authorization server?

The answer isn’t obvious, because it depends on how your MCP server is architected. But even worse, most explanations of MCP forget to include a critical piece of the authentication flow.

MCP authorization server

What’s overlooked in the core of MCP architecture is the role of the authorization server, which is a core role within the OAuth flow responsible for issuing access tokens to the client after successful authentication.

While we commonly talk about the three main components—MCP clients, MCP servers, and third-party services—there’s a critical fourth player that handles authentication and access control within the MCP flow.

1. MCP clients
2. MCP servers
3. Third-party services
4. Authorization server (OAuth handling)

The authorization server is what makes secure, user-consented OAuth flow possible in MCP. It’s responsible for:

• Issuing signed access tokens with embedded claims
• Supporting OAuth 2.1 flows (e.g., Authorization Code with PKCE) we mentioned before
• Presenting consent screens
• Enforcing token lifetime, refresh logic, and revocation
• And more

But if the authorization server plays such a key role, why isn’t it shown in most standard MCP diagrams? There are a few reasons:

• Most MCP servers are still local implementations using stdio without auth. This will change dramatically with the rise of remote MCP servers.
• Authorization server implementations are not finalized in the MCP specification (here’s an active discussion among developers).
• There’s more than one way to implement it.

Two architectures for MCP authorization servers

When designing an MCP server, one of the most important authentication decisions you’ll face is whether your server will act as an Identity Provider or a Relying Party in the OAuth exchange.

There are two primary ways to implement the authorization server within the MCP architecture:

1. Embed the authorization server within the MCP server, effectively making the MCP server an Identity Provider that handles login, consent, and token issuance directly. This is why most MCP explanations don’t mention the authorization server. They assume the MCP server is the authorization server.
2. Delegate to an external authorization server, which makes your MCP server a Relying Party in the OAuth exchange—consuming third-party tokens and mapping them to internally scoped permissions.

Both approaches are valid under the MCP specification and each comes with its own tradeoffs in complexity and integration effort. This choice influences how much OAuth infrastructure you need to manage within the MCP server itself.

Embedding the authorization server

In this architecture, the MCP server includes its own built-in authorization server. It acts as both the Identity Provider and Relying Party, managing the entire OAuth 2.1 flow internally.

The MCP server is effectively responsible for everything:

• Handling incoming requests from the MCP client
• Presenting login and consent screens
• Issuing signed access tokens with embedded identity and scope claims
• Validating tokens and enforcing access control policies
• Supporting OAuth 2.1 features like Authorization Code with PKCE
• Managing token lifetimes, refresh logic, and revocation

Some developers have raised concerns that requiring MCP servers to also be an authorization server is too much of a burden. For many use cases, this coupling may be unnecessary and costly to integrate.

Delegating to an external authorization server

Here, the MCP server delegates the entire OAuth flow to an external authorization server or service. The MCP server acts as a traditional OAuth Relying Party, consuming tokens issued by a separate Identity Provider.

Here, the MCP server is only responsible for:

• Handling MCP client requests
• Mapping identity claims and scopes to internal permissions
• Validating external access tokens (this could also be handled by the external auth server)

This architecture follows the OAuth best practice of separating concerns between the authorization server and the resource server. It enables teams to reuse existing identity infrastructure or integrate auth providers like Stytch, while focusing solely on defining and enforcing tool-level access.

A quick glance side-by-side

An evolving specification

Keep in mind that the MCP specification is actively changing. Updates are being proposed and merged on a regular basis (like this open PR that outlines some upcoming authorization changes).

It’s a good idea to keep an eye on the latest pull requests and ongoing discussions in the official MCP repo to stay aligned with the direction of the protocol.

Stytch Connected Apps: Building secure auth for MCP

MCP gives us a powerful way to structure and standardize how agents interact with external services. But that power depends on a well-designed authentication and authorization layer.

No matter how you architect your MCP server, Stytch Connected Apps provides everything you need to deliver secure, OAuth compliant authorization sever.

For a hands-on look, check out our MCP to-do list example app or B2B MCP OKR manager example app see how the OAuth flow code is structured and executed between MCP client and server.

Stytch provides a toolkit to create OAuth compliant Identity Providers to support both use cases:

• Is your MCP Server more of a standalone application? Stytch enables you to turn the MCP server itself into an Identity Provider.
• 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.

With Connected Apps, you can offload the engineering work and hardest parts of building OAuth infrastructure. Stytch handles:

• 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 how MCP fits into your stack? Interested in building secure agentic integrations without rebuilding your auth layer from scratch?

Contact us for a demo or sign up and check out our MCP quickstart guide.