Authorization: MCP’s less-talked about fourth pillar

Anthropic has released a significant update to the Model-Context Protocol (MCP) specification, marking an important evolution in MCP infrastructure. Among other updates, a crucial update directly addresses one of the core but often overlooked pillars of MCP architecture: authorization.

Let’s understand why this is important. MCP architecture discussions usually focus on on three main components:

• Hosts: LLM applications such as Claude Desktop or IDEs, which initiate connections
• MCP clients: They reside within the host, establishing and maintain 1:1 connections with MCP servers
• MCP server: Provide resources, prompts, tools, etc. to MCP clients.

Often missing from this list is the fourth and arguably most security-sensitive player: the authorization server.

This server is responsible for managing authentication, issuing access tokens, handling consent flows, enforcing token lifetimes, and validating permissions. In short, it is the core of the OAuth flow that MCP builds on. Yet, it is routinely left out of the conversation.

With Anthropic's recent spec update, this missing pillar is now officially integrated into MCP’s architectural foundation. Let’s take a deeper look at the significance of the recent announcement:

• MCP servers no longer issue access tokens or handle user authentication.
• Dedicated authorization servers handle all aspects of user authentication and token issuance.
• RFC9728 (Protected Resource Metadata) lets MCP clients dynamically discover the appropriate authorization server.
• RFC8707 (Resource Indicators) is now required for enhanced security.

Why auth gets overlooked

Early MCP implementations are mostly local, single-user, and operated over stdio or UNIX sockets, with no auth required. Plus, the specification has been evolving rapidly, leaving many decisions to individual developers.

Devs are building MCP servers that double up as both resource and authorization servers. That means they are minting, signing, rotating, and validating tokens on their own.

Consider what this means. Every developer who builds a tool on top of MCP also needs to:

• Implement OAuth 2.1 securely
• Handle token signing and cryptographic key rotation
• Design consent and access delegation flows
• Store, refresh, and revoke tokens reliably

As more MCP servers go remote and integrate with sensitive services, this ambiguity becomes a liability. Teams are left to make decisions about authorization infrastructure without clear guidance. Increasingly, they choose to fold auth into the MCP server itself, creating risk.

Unless your team specializes in identity and security infrastructure, this is a recipe for trouble.

Do you trust every developer writing an MCP server to know how to mint, sign, rotate, and validate tokens securely? The risk of getting it wrong is very high if this isn’t what you do day in and day out — Den Delimarsky, Product Manager, Microsoft

A shift toward specialized authorization

Initially, MCP servers were often built with embedded authorization capabilities. This meant a single server handled both providing resources and managing tokens and user authentication. Initially convenient, this approach has become increasingly problematic as MCP has scaled beyond simple local integrations.

Why embedded auth was common (But problematic)

Early MCP implementations, often local and single-user, didn't need sophisticated authentication. Developers naturally built authentication into their resource servers, and combined the following roles:

• Handled login and consent
• Issued its own signed tokens
• Enforced scopes and lifetimes
• Validated incoming requests

This might sound efficient, but it tightly couples your tool logic to complex auth behavior. Unless you are an identity expert, you are likely to miss critical edge cases or introduce vulnerabilities.

When authorization responsibilities are embedded directly into the MCP server, developers effectively create a system that handles both resource management and token issuance internally.

On the surface, this might seem beneficial. It provides complete control over authentication flows, simplifies initial integration, and can tightly couple consent mechanisms directly with the server’s internal processes.

However, embedding authorization within your MCP server also introduces several challenges:

• Complexity and workload: Managing OAuth 2.1 authorization internally requires significant knowledge of cryptographic best practices, token lifecycle management, and secure data handling. Your team must continuously maintain and audit this custom-built authorization infrastructure, which can divert resources away from core product innovation.
• Security vulnerabilities: Even minor oversights in token issuance, refresh logic, or validation mechanisms can introduce serious vulnerabilities. Common mistakes include:
  • Token leakage
  • Weak cryptographic implementations
  • Improper key rotations
  • Scope mismanagement, all of which could lead to unauthorized access or data breaches.
• Scalability and maintenance issues: Scaling a combined server and authorization infrastructure becomes increasingly complex. Every new feature or scope addition demands careful integration and validation across the entire stack, slowing down agility and responsiveness to new requirements.

Example: Internal audit tool at a financial services firm

Let’s look at a scenario when an embedded MCP server was still a thing. A fictional financial services company built an internal auditing tool using MCP with embedded authorization. Here’s precisely what the MCP server does:

• Authentication: Presents an internal login form directly integrated with the company's user directory.
• Consent management: Shows a simple internal consent screen, explicitly listing permissions such as ^{audit:account:view} and ^{audit:report:create}.‍
• Token management: Generates and digitally signs JWT tokens internally, embedding specific user roles, permitted scopes, and expiration details.‍
• Authorization validation: For every request (e.g., viewing audit logs or creating audit reports), the MCP server internally verifies tokens, matches permissions with requested actions, and authorizes or denies requests.‍
• Auditing: Logs every authorization decision internally for compliance tracking.

Outcome: This approach gives the company direct, secure internal control but requires continuous maintenance and dedicated security expertise to manage the token lifecycle securely.

The new MCP approach: External authorization servers

Recognizing these issues, the latest MCP specification mandates separating authorization logic from the MCP server itself. MCP servers now exclusively act as resource servers, verifying tokens issued by trusted external authorization servers.

As OAuth veteran Aaron Parecki put it:

"Just treat every MCP client as an OAuth client. Treat the MCP server as a resource server that uses an existing authorization server to mint trusted tokens. That’s it. Problem solved."

This approach positions the MCP server as a straightforward resource server, delegating token management to a dedicated, trusted identity provider.

Advantages of this approach include:

• Reduced complexity and lower operational overhead: By offloading authorization to a specialized service, your team can concentrate on core functionalities without needing extensive security or OAuth domain knowledge. This significantly simplifies your implementation and operational processes.
• Enhanced security posture: External authorization providers invest considerable resources into continuously improving their security infrastructure, including comprehensive audits, penetration testing, and regular compliance updates. This significantly reduces the likelihood of token mismanagement or cryptographic failures, leveraging the expertise of industry leaders.
• Improved scalability and agility: External auth providers offer robust and scalable infrastructure. Adding new features, modifying scopes, or supporting new types of clients can be accomplished quickly and reliably, facilitating agile development and rapid iteration.
• Better interoperability and integration: An external auth solution provides standardized APIs and industry-standard integration patterns. This helps ensure compatibility across different MCP clients and tools, simplifying the integration of new applications or services into your existing infrastructure.

Leveraging external authorization providers thus allows MCP servers to focus on their primary role: efficiently serving authenticated and authorized requests, while securely delegating identity management tasks to dedicated specialists.

Learn more : Embed vs External Authorization in MCP

Example: Developer analytics SaaS with Scalekit for MCP auth

A fictional developer analytics SaaS platform needed to let third-party developer tools query usage metrics, debug user behavior, and modify dashboards on behalf of individual users.

To simplify secure delegation, they exposed a standardized MCP server as the interface for all tool interactions. Rather than building auth logic in-house, let’s assume they use Scalekit as the external authorization layer.

Scalekit provided a full OAuth 2.1-compliant authorization server, enabling the platform to focus entirely on its MCP server’s resource responsibilities.

Here’s what the flow looks like:

• Dynamic client registration: MCP clients can dynamically register with Scalekit at runtime. This means tools do not need to be manually pre-provisioned. The server handles metadata like redirect URIs, supported grant types, and requested scopes automatically.
• OAuth 2.1 flows with PKCE: When a developer tool initiates a flow, it uses Authorization Code flow with PKCE. This ensures tokens cannot be intercepted or replayed, even if the client is a public CLI.
• User-backed tokens with consent: During auth, Scalekit presents a consent screen to the end user—typically a developer or analyst—clearly stating which permissions the tool is requesting (e.g., ^{analytics:data:read}, ^{dashboard:modify}). Users must explicitly approve this before any token is issued.
• Token issuance and expiry: Once authorized, Scalekit issues short-lived access tokens (JWTs) that encode identity, scopes, and expiry. These are signed and auditable. The MCP server simply verifies the token against Scalekit’s published public keys.
• Authorization inside the MCP server: For each incoming request, the MCP server validates the token, maps scopes to internal permissions, and allows or denies actions accordingly. For example, a token with ^{dashboard:modify} allows editing UI views, but cannot access usage logs (^{analytics:data:read}).

Outcome: With Scalekit handling registration, consent, token minting, and validation infrastructure, the platform accelerated development, reduced security burden, and enabled user-delegated access at scale. The MCP server remained cleanly scoped: just a resource layer enforcing trusted, externally-issued authorization decisions.

Comparing older and new spec authorization servers

The new spec update solves for complexity, security risk, and maintainability.

Embedded authorization can offer fine-tuned control but introduces significant operational complexity and requires specialized security expertise.

On the other hand, external authorization leverages established identity infrastructure, significantly reducing implementation overhead, minimizing security risks associated with token management, and streamlining ongoing maintenance.

Here’s a comparison table:

Embedded vs. external authz servers

Implementing fine-grained authorization

A critical aspect in MCP authorization is the implementation of fine-grained, tool-specific authorization policies. While standard OAuth scopes generally map to broad API-level permissions, MCP interactions often occur at a more granular tool or function level.

This means authorization checks must go beyond simply validating tokens at an API boundary. Instead, MCP servers should enforce permissions directly tied to the specific tool actions or agent behaviors requested by MCP clients.

For example, rather than using a broad scope like ^read:data, a tool-specific permission like ^{tool:codegen:execute} or ^{tool:debug:inspect} allows servers to precisely control what an MCP client is allowed to do. This level of detail ensures users grant only the exact permissions needed, significantly reducing the risk of over-permissioning and unintended access.

Implementing fine-grained authorization policies aligned with tool-level interactions is essential for both security and usability, particularly in agent-driven experiences.

The spec is still evolving, but act now

The latest MCP spec drafts are still evolving: every few weeks, we get an update. There is active discussion around formalizing how authorization should work, and contributors are zeroing in on best practices.

However, if you are building agent-driven tools today, act immediately.

Treat your MCP server as an OAuth resource server.

Let token minting, signing, and validation be handled by trusted, battle-tested infrastructure. Keep your auth flows decoupled, your roles well-defined, and your users (and their data) secure.

Ready to offload the complexity of issuing and managing tokens for MCP? Sign up for a Free Forever account with Scalekit and let our OAuth 2.1-compliant authorization server handle auth, signing, and token validation for your MCP servers. Have questions on how to integrate or migrate? Book time with our auth experts.

FAQs

What is the fourth pillar of MCP architecture?

The authorization server is the critical fourth pillar often ignored in early MCP discussions. While hosts, clients, and servers handle communication and resources, the authorization server manages authentication, token issuance, and consent flows. It serves as the foundation of the OAuth flow that ensures secure access. Without this dedicated component, developers are forced to handle complex cryptographic tasks like key rotation and token validation themselves. Centralizing these responsibilities within a specialized server improves the overall security posture and allows the MCP server to focus strictly on serving resources.

Why is embedding authorization in MCP servers risky?

Embedding authorization logic directly into an MCP server creates significant security and operational liabilities. Developers must manually implement OAuth 2.1, manage cryptographic key rotations, and design secure consent flows. This tight coupling increases the risk of token leakage, weak cryptographic implementations, and scope mismanagement. Furthermore, maintaining custom auth infrastructure diverts engineering resources away from core product innovation. As MCP servers scale or move to remote environments, these internal systems become harder to audit and more susceptible to vulnerabilities compared to using a dedicated, battle tested identity provider.

How does RFC9728 improve MCP client security?

RFC9728 introduces Protected Resource Metadata, allowing MCP clients to dynamically discover the correct authorization server for a specific resource. This mechanism enhances security by ensuring that clients interact with legitimate, verified identity providers rather than hardcoding endpoints. By automating discovery, developers can more easily manage complex environments where multiple MCP servers and authorization servers coexist. This standardizes how clients find the necessary security infrastructure to request access tokens, reducing configuration errors and preventing unauthorized actors from intercepting sensitive authentication requests during the initial connection phase of the protocol.

What role does an external authorization server play?

An external authorization server like Scalekit acts as a trusted third party that handles identity management tasks. It manages user logins, presents consent screens, and issues short lived JWT access tokens. By delegating these responsibilities, the MCP server acts strictly as a resource server that only needs to verify incoming tokens. This separation of concerns ensures that sensitive cryptographic operations and user data are handled by specialized infrastructure. It also enables better interoperability across different tools and platforms by using standardized APIs and industry standard integration patterns for authentication and authorization.

Why is OAuth 2.1 with PKCE necessary for MCP?

Using OAuth 2.1 with Proof Key for Code Exchange is vital for securing MCP connections, especially for public clients or remote tools. PKCE prevents authorization code injection and interception attacks by ensuring that only the client that initiated the request can exchange the code for a token. This is particularly important as MCP environments evolve from local single user setups to distributed multi user systems. Implementing these modern standards ensures that access tokens remain secure even if communication channels are compromised, providing a robust defense against sophisticated replay and impersonation attacks.

What is the benefit of Dynamic Client Registration in MCP?

Dynamic Client Registration allows MCP clients to register with an authorization server at runtime without manual pre provisioning. This automation simplifies the onboarding of new developer tools and agent applications by automatically handling metadata like redirect URIs and supported grant types. For engineering managers, DCR reduces the administrative burden of managing thousands of client credentials manually. It provides a scalable way to authorize diverse tools while maintaining strict control over which applications can request access to sensitive resources, thereby streamlining the integration process for complex B2B ecosystems.

How should developers implement fine grained authorization in MCP?

Developers should implement authorization policies that map to specific tool actions or agent behaviors rather than broad API scopes. Instead of generic read or write permissions, use granular indicators such as tool codegen execute or tool debug inspect. This ensures that users and agents grant only the precise level of access required for a specific task. By enforcing these checks at the function level, MCP servers can prevent over permissioning and limit the blast radius of potential compromises. This granular approach is essential for maintaining trust in agent driven workflows and AI applications.

What distinguishes a resource server from an authorization server?

In the updated MCP architecture, the resource server and authorization server have distinct responsibilities. The authorization server is responsible for authenticating users, managing consent, and minting cryptographically signed tokens. In contrast, the MCP server acts as the resource server, which receives these tokens and validates them against the authorization server public keys. The resource server focuses on executing requested tools and returning data based on the permissions encoded in the token. This separation simplifies the architecture, improves security, and ensures that each component can be scaled and audited independently.

How do external providers simplify MCP server maintenance?

External authorization providers significantly reduce the maintenance burden by handling complex updates and security patches. They invest in continuous security audits, penetration testing, and compliance updates that most internal teams cannot afford to perform regularly. By offloading token lifecycle management and cryptographic rotations, developers can focus on building core MCP features rather than troubleshooting identity issues. This specialized infrastructure provides high availability and scalability out of the box, ensuring that authorization services remain resilient as the number of users and integrated tools grows within the organization.

‍