MCP SSO: All Your Tools, Everywhere

TL;DR mcp.run has built the first Single Sign-On (SSO) solution for the MCP ecosystem, providing a way for users to maintain a suite of pre-installed, pre-authenticated MCP servers in portable "profiles" that can be used across any MCP-compatible application. This flips traditional integration models by letting users decide which integrations they bring to applications rather than being limited to what the app developer chose to make available.

Book a demo →

Since we've been building MCP infrastructure over the past six months, it has become clear that integrations and the way applications manage them has changed forever:

The future belongs to user-driven integrations, not app-defined ones.

A couple of months ago, I posted on X:

Today, I'm excited to say that this is a reality! With mcp.run's SSO solution, users can freely manage all their MCP server tools (hosted or remote) in one place, storing authenticated connections into profiles. Access to the tools in a profile can be granted securely to any application which may then use those tools on their behalf.

For applications, this means they are no longer required to build credential management, authentication flows, or maintain OAuth clients for every integration they want to support. Just a single, secure OAuth connection with mcp.run.

The New Frontier of AI Application Integration

AI applications are rapidly transforming how we interact with software, but they face a critical challenge: connecting with the systems where our data and tools live. While the Model Context Protocol (MCP) provides an elegant way for AI to interface with tools through intent-based communication, the question of identity and authentication remains unsolved.

When every AI application wants to connect to dozens of potential services, how do we manage the authentication flow, security, and permissions for each connection? Current approaches create significant friction for users who need to constantly re-authenticate and re-connect their services across different applications.

User-Driven vs. App-Defined Integrations: A Paradigm Shift

In the traditional app-defined integration model, developers pre-select which third-party services their application will support:

• Your CRM might offer integrations with Gmail, Outlook, and Slack
• Your project management tool connects with GitHub, Jira, and Asana
• Your analytics platform pulls data from Google Analytics, Mixpanel, and HubSpot

As a user, you're limited to the connections the app developer chose to build. If your team uses a less common email provider or a specialized tool, you're out of luck unless the app developer decides it's worth supporting.

User-driven integrations flip this model entirely:

• Instead of apps deciding which integrations you can use, you bring your own suite of pre-authenticated tools
• Instead of connecting the same services repeatedly in each new application, you authenticate once and reuse those connections
• Instead of being limited to what the developer prioritized, you can use any tool that offers an MCP Server

This is the difference between "We've added Google Calendar integration!" and "Use any calendar service you want, as long as it has an MCP server."

Introducing the SSO for MCP

To enable this user-driven integration model, mcp.run has built the first SSO solution specifically designed for the Model Context Protocol ecosystem.

How It Works

Our platform provides users with "profiles" – collections of pre-installed, pre-authenticated MCP Servers that can be securely accessed by any MCP Client application:

1. Users create and manage profiles containing the tools they use
2. MCP Server connections are authenticated once and securely stored
3. OAuth integration allows any MCP Client application to request access to a user's profile
4. Permission management gives users control over which applications can access which tools

This creates a portable identity and access control layer that makes all your MCP tools available to any compatible application.

As seen in the diagram below, a user grants an application to access profiles they create on mcp.run.

Wait, don't MCP clients want to talk to MCP Servers not "profiles"? Yes! a profile on mcp.run is actually a dynamic, virtual MCP Server, which we bundle for the user. Installing anything into a profile flattens the tools from many MCP Servers into a single MCP Server.

This user created a profile that provides access to tools from Excel, Sentry, and Gmail, but not from Salesforce, Cloudflare, or GitHub - though they could be managing those in a different mcp.run profile!

The mcp.run SSO solution consists of a few key components:

1. Profile Management: Where users install and configure their MCP Servers (in profiles on mcp.run)
2. Authentication Management: Handles user identity and secure OAuth flows, storing and updating access credentials centrally
3. Access Control Layer: Manages permissions for client applications, authorized via OAuth
4. MCP Server Delivery: Bundles multiple MCP Servers into a unified MCP Server (delivered as the profile)
5. Client Registry: Manages registered MCP Client applications, so users know what has access to their tools

When a user connects an MCP Client application to their profile, they see a consent screen like this:

This allows the user to explicitly authorize what the application can access, maintaining security while enabling seamless connections.

The Power of Profiles for Context Management

Profiles serve another crucial purpose beyond authentication: efficient context management.

When working with LLMs, every tool description consumes valuable context window space. Rather than constantly enabling and disabling individual tools — an arduous process in most MCP clients — profiles allow you to:

• Create purpose-specific toolsets: Build different profiles for development, productivity, research, or creative tasks
• Minimize context window usage: Only include the tools relevant to your current task
• Quickly switch contexts: Change your entire toolset with a single profile switch instead of toggling dozens of individual tools
• Optimize for performance: Deliver only the useful subset of MCP Server tools at a time, preserving context window for your actual work

With mcp.run's profile management, you can craft toolsets tailored to specific purposes and switch between them effortlessly. This solves a significant pain point for MCP users who otherwise struggle with overflowing context windows or constantly reconfiguring their tool access.

Does MCP Need Its Own SSO Solution?

The Challenge of Managing Multiple Authenticated Connections

Without a centralized authentication layer for MCP:

• Users must repeatedly authenticate the same services across different applications
• Developers must implement OAuth flows for each service they want to support, and maintain OAuth clients for every integration
• Security becomes inconsistent with varying levels of protection across integrations, and end-users need to recall which apps have access to their tools
• Permission management becomes fragmented across multiple applications

But authentication is just the beginning. The real value of a dedicated MCP SSO solution extends far beyond merely identifying users:

• Runtime control: With mcp.run, users gain unprecedented control over how their tools are accessed and used in real-time. They can pause access, modify permissions, or revoke connections instantly across all applications.
• Comprehensive observability: Our platform provides visibility into which tools are being used, how frequently, by which applications, and for what purposes - offering insights that would be impossible with disconnected authentication systems.
• Centralized audit trails: Every tool invocation is logged and viewable, creating accountability and transparency that's critical for sensitive enterprise environments.
• Usage patterns and analytics: Users can see how their tools are being utilized across different applications, helping optimize their workflows and profile configurations.

This level of control and observability is impossible with traditional, fragmented authentication approaches, where each integration operates in isolation with no unified oversight.

How OAuth and SSO Traditionally Solve Identity Challenges

Traditional identity solutions like OAuth and SSO have solved these problems for web applications:

1. OAuth allows users to grant limited access to their accounts without sharing credentials
2. SSO enables users to access multiple applications with a single login
3. Permission scopes provide granular control over what applications can access

While existing protocols provide a foundation, MCP presents unique challenges:

1. Tool discovery needs to be user-centric, not application-centric
2. LLM agents need secure access to multiple systems simultaneously
3. Permission management needs to be granular yet simple for users to understand
4. Connections need to be portable between different MCP Client applications

The mcp.run SSO solution builds on OAuth standards while addressing these specific needs of the MCP ecosystem.

User Choice is Now Critical

As AI assistants become central to our workflows, they need access to whatever tools and data we use. User-driven integrations are essential because:

1. AI operates across domains: An assistant might need to access your email, calendar, CRM, and project management tools in a single session
2. Personalization matters: The tools each user needs vary widely
3. Specialized tools proliferate: No app developer can anticipate and support them all
4. Integration expectations rise: Users expect AI to work with all their systems, not just popular ones

Flipping the Integration Model

Traditional integration: "Here are the services our app connects with."
User-driven integration: "Here are the services I want to use with your app."

This flips the responsibility from application developers to users, empowering people to create their own integration ecosystems that travel with them across applications.

With mcp.run's SSO platform for MCP, the power shifts to users who can decide which integrations they bring to any application. This isn't just about convenience—it's about giving users true ownership over their digital tools and how they're used.

Real-World Benefits

The combination of MCP and a unified identity layer enables numerous practical benefits:

For Users

• Authenticate once: Connect your tools a single time instead of repeatedly across applications
• Consistent experience: Your preferred tools follow you across any MCP-compatible application
• Granular control: Grant and revoke access to specific tools on a per-app basis or across all apps at once
• Privacy protection: Maintain oversight of how applications use your tools and data

For Developers

• Reduced complexity: Implement one OAuth flow instead of dozens
• Faster time-to-market: Skip building and maintaining authentication systems for each integration
• Broader tool ecosystem: Offer access to thousands of tools without building each connection
• Focus on core product: Let users bring their tools rather than deciding which to support

For Enterprises

• Governance and compliance: Centralized audit trails and permission management
• Security standardization: Consistent authentication practices across integrations
• Risk reduction: Quickly revoke access across all applications when needed
• Resource optimization: Eliminate duplicate integration work across teams

Unlocking the Potential of MCP

The Model Context Protocol has provided a powerful way for AI systems to interact with external tools, but without a unified identity layer, its potential remains constrained by authentication friction and fragmented connections.

mcp.run's SSO solution for MCP addresses this critical gap, enabling truly user-driven integrations where people can bring their own pre-authenticated tools to any compatible application.

This shift from app-defined to user-driven integrations represents a fundamental change in how we think about software integration – one that puts users in control and creates a more flexible, powerful ecosystem for AI applications.

We believe that every application will become an MCP client, and they'll need infrastructure like ours to manage the connectivity and collection of MCP servers their users want to integrate. We're building that infrastructure today.

Reach out to get a preview and sign up for early access. We're rolling this out to select partners now, and aiming for general availability in a couple of months. You can also book a demo and learn more about how to leverage MCP in your own applications.

---

This blog post is part of our series on MCP infrastructure. Read our previous post on MCP as a differential for modern APIs.