OAuth-Secured MCP Factory

This blueprint demonstrates how to secure multiple MCP server integrations behind a single OAuth connection using Google as the identity provider. It is a pattern every team should consider when exposing AI capabilities through MCP to external clients such as Claude, Cursor, Windsurf, and other MCP-compatible tools.

Why OAuth Matters for MCP Servers

MCP servers expose powerful abilities - database queries, file operations, API calls, and more - to any client that connects. Without authentication, anyone with the server URL gains full access. The OAuth connection solves this by requiring users to authenticate through a trusted identity provider (in this case Google) before they can invoke any tool. This means only verified users within your organization can access your MCP servers, providing an excellent way to secure them without managing API keys or tokens manually.

The OAuth connection handles the full OpenID Connect flow: it validates the user's identity token against Google's issuer, checks that the email domain belongs to your organization (via allowed domains), and can enforce additional required claims. All of this happens transparently - the MCP client simply opens the authentication URL, the user signs in with their Google account, and they are granted access.

Architecture Overview

The blueprint defines three MCP server integrations, each connected to its own skillset with specialized abilities:

• Productivity Server - Connected to a skillset with calendar and document management abilities. Useful for scheduling, meeting notes, and document retrieval.
• Data Server - Connected to a skillset with database query and reporting abilities. Useful for analytics, dashboards, and live data lookups.
• DevOps Server - Connected to a skillset with deployment and monitoring abilities. Useful for checking service health, triggering builds, and reviewing logs.

All three MCP server integrations reference the same OAuth connection. This means a single Google sign-in grants access across all servers for the authenticated user, while unauthorized users are blocked from every server uniformly.

Skillset Isolation

Each MCP server integration is connected to its own skillset. This is deliberate - it provides clear capability boundaries. The Productivity Server can only invoke calendar and document abilities, the Data Server can only run queries, and the DevOps Server can only perform deployment operations. A client connected to one server cannot reach abilities belonging to another. This isolation makes it safe to grant different teams access to different servers while maintaining a single sign-on experience through the shared OAuth connection.

Extending the Pattern

Because each skillset is independent, adding new capabilities is straightforward: create a new ability, attach it to the relevant skillset, and it becomes available through the corresponding MCP server immediately. Need a new server for a new domain? Add another MCP server integration, give it its own skillset, and point it at the same OAuth connection. The authentication layer stays consistent while capabilities grow.

This method allows for building and extending the capabilities of Claude and other MCP-compatible tools incrementally. Teams can ship new abilities behind secure, authenticated MCP endpoints without re-deploying or reconfiguring existing infrastructure.

Google as Identity Provider

Google is used here because it is the most common identity provider for organizations already on Google Workspace. The OAuth connection is configured with Google's OpenID Connect issuer URL, your OAuth client credentials, and an allowed domains list restricted to your company domain. You can substitute any OpenID Connect-compliant provider (Okta, Auth0, Azure AD, etc.) by changing the issuer URL and credentials.