--- title: "Why MCP Gateways Should Use Existing Authentication Services" description: "An MCP gateway shouldn't replace the IdP you already run. Here's why identity servers and MCP gateways work best as separate, complementary concerns — and what 'bring your own IdP' should mean in practice." canonicalUrl: "https://zuplo.com/blog/2026/08/19/mcp-gateways-existing-auth-services" pageType: "blog" date: "2026-08-19" authors: "billDoerrfeld" tags: "MCP, AI Gateway, API Security" image: "https://zuplo.com/og?text=Why%20MCP%20Gateways%20Should%20Use%20Existing%20Auth" --- Enterprises are increasing their use of MCP throughout software development and business workflows. However, when you scale MCP you run into a bit of an authentication dilemma: How do you federate authentication to backend services across various services without reinventing the wheel or sacrificing your existing identity provider (IdP)? Trust should remain rooted in your existing identity and access management (IAM) system, rather than being recreated separately within individual MCP servers or gateways. And thankfully, you don't need to buy into completely new authentication systems to govern MCP — it's become a standard across [MCP gateways on the market](https://zuplo.com/blog/mcp-gateway-comparison) to integrate with existing IAM platforms. In short, gateways and IAM should remain separate concerns. Below, we'll look at the authentication burdens facing MCP in practice, and see why authentication should be [decoupled from your MCP servers](https://zuplo.com/blog/decouple-agent-auth-mcp-server). We'll explore the advantages of retaining your existing identity server as you begin to govern access to more and more upstream MCP servers. ## The authentication burden of MCP Enterprise software environments are beginning to juggle various MCP servers within heterogeneous AI platforms. Zuplo's [State of MCP Report](https://zuplo.com/mcp-report) found that 70% of developers using MCP already have 2-7 MCP servers actively configured. The thing is, authentication is complex. Each MCP server handles authentication in its own way: although OAuth is common, some rely only on API keys. And, each agentic platform handles user authentication differently, as well. Beyond authentication, agentic systems need securely scoped access to underlying tools to ensure agents have the right permissions. Authentication barriers can stunt the rollout of MCP initiatives. In fact, security and compliance concerns were the top issue preventing increased MCP use, found the aforementioned Zuplo report. Security and access control complexity as well as integration with existing systems remain top challenges for those building MCP servers as well. Thankfully, standards are emerging around MCP authentication and authorization. For example, MCP's [Enterprise-Managed Authorization extension](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization) now provides a standardized way to control MCP access through an existing IdP. However, implementations still remain inconsistent, and agentic systems can fall victim to an assortment of [security flaws](https://zuplo.com/blog/7-common-mcp-security-flaws), including: - Unauthorized usage of untrusted MCP servers - [Shadow MCP servers](https://zuplo.com/blog/how-to-avoid-shadow-mcp-servers) and MCP server sprawl - Insecure token and credential handling practices - Broken identity control and overpermissioned access There are really two authentication problems at play. Enterprises must authenticate users and clients connecting to the gateway, while the gateway must separately authenticate to upstream MCP servers, which may each expect different OAuth tokens, API keys, or other credentials. ## Trust should remain in your IAM [MCP gateways](https://zuplo.com/blog/mcp-gateway-buy-or-build) can help with many aspects of securing agent-driven MCP interactions. They're a helpful utility for enacting observability, routing, rate limiting, and scoping tool access. However, they shouldn't replace the enterprise identity systems already responsible for establishing user identity and trust. This is where existing identity and access management (IAM) systems come into play, particularly identity providers (IdPs) that manage authentication and identity federation. These systems typically support OAuth 2.0 and OpenID Connect (OIDC) flows to authenticate users and delegate secure, trusted access to underlying APIs. Common enterprise IdPs include Microsoft Entra ID (formerly Azure AD), Auth0, and Okta. However, other access infrastructure providers, like Arcade.dev, Ping Identity, Curity, and others, are also growing in use. Such authentication services excel at standards-based access delegation. For instance, they can enable Authorization Code Flow with PKCE (Proof Key for Code Exchange), consistent with modern OAuth security practices. Their capabilities make IdPs an important trust layer for guiding complex token validation flows and avoiding long-lived keys. ## Benefits of using an IdP _and_ MCP gateway Authentication services like IdPs are a backbone of modern identity and access control throughout enterprises. And, there are multiple benefits of using an existing authentication service, like an IdP, alongside an MCP or AI gateway. ### Guides internal enterprise governance First, IdPs already play an important role in modern enterprise architectures, validating access to internal and partner-based business functions that are exposed as APIs. Access through MCP to such services should be no different: it should utilize the same IdP to establish user identity and govern access to backend services. By using your existing IdP, you avoid the risk of creating multiple parallel identities. For agentic systems, the identity server remains the authoritative identity layer, fitting MCP access into existing corporate norms for authentication and access. ### Re-uses existing investment Enterprises have already made considerable investments into their internal IAM and authentication services. By introducing entirely separate authentication methods, you risk bypassing a valuable security layer and fracturing authentication into various bespoke styles across platforms. By using an IdP alongside an MCP gateway, you reap the investments you've already made into a stable authentication service or IAM layer. ### Retains your identity trust layer Without integrating your existing identity layer, you can lose foundational controls used to establish identity and delegate trusted access to external APIs. By integrating your authentication platform, you bring an additional level of trust and verification for API-native identity federation and delegation. With this layer, you decrease the likelihood of introducing inconsistent authentication practices. ### Separation of concerns Lastly, a [separation of concerns approach](https://nordicapis.com/separation-of-concerns-soc-the-cornerstone-of-modern-software-development/) makes a lot of sense, especially when securing multi-agent environments that connect to various external tools. In this model, you outsource enterprise identity management and user authentication to an authentication service, and let the gateway handle the intricacies of MCP routing, policy enforcement, credential brokering, and traffic management. Separating concerns affords best-of-breed standard components that can be reused across AI or agent environments. ## Gateways should allow 'bring your own' IdP For these reasons and others, an [enterprise MCP gateway](https://zuplo.com/blog/why-enterprises-need-an-mcp-gateway), therefore, should integrate with existing authentication services like identity providers. It should be flexible enough to integrate common IdPs, as well as additional or custom identity providers. For instance, [Zuplo MCP Gateway](https://zuplo.com/mcp-gateway) works with third-party IdPs by default, allowing administrators to configure access to whatever identity provider they already use, whether it's Auth0, Okta, Microsoft Entra ID, WorkOS, PingOne, Google, or any other OpenID Connect (OIDC) provider. With Zuplo, the process looks like this: 1. You choose the IdP your organization already uses. 2. The user authenticates through that IdP. 3. The gateway issues a short-lived token scoped to the virtual MCP server. 4. The gateway separately brokers the credential required by the upstream MCP server. 5. The client never needs the backend credential. By taking this sort of 'bring your own' approach to IdPs, MCP gateways can remain agnostic to the base identity and access mechanisms that enterprises already use, allowing them to repurpose them for new AI initiatives and MCP server adoption. ## MCP gateways and IAM systems: complementary tools Authentication services like identity platforms should be seen as complementary to new [MCP infrastructure](https://zuplo.com/blog/mcp-registry-vs-mcp-gateway) such as MCP registries and gateways. This is no different to how IdPs have supported AI and API gateways in the past. Gateways and IAM systems are complementary because they perform discrete functions: - **MCP gateway**: The layer that handles MCP traffic, enabling discoverability, routing, credential brokering, scoped tool access, and [auditing of MCP tool calls](https://zuplo.com/blog/audit-agent-mcp-tool-calls). - **Authentication service**: The IdP or identity platform that authenticates users and clients, participates in OAuth/OIDC flows, and establishes the identity and claims used to govern access. To put it simply, if a gateway is the front door for requests to AI tools, the identity server is the badge system that determines who is coming through it. Together, both MCP gateways and authentication services provide a comprehensive means to help govern and secure MCP server access at scale throughout an organization.