MCP server authentication still hinges on OAuth complexity

At a glance

What this is: This is an analysis of MCP server authentication and authorization, showing that OAuth bridging reduces implementation friction but does not remove the underlying identity and secret-management risk.

Why it matters: It matters because MCP becomes part of the identity perimeter as soon as agents and tools exchange tokens, which changes how IAM, NHI, and governance teams need to think about authorization scope, consent, and secret exposure.

By the numbers:

• 60%, t MCP servers, around 60%, require you to provide an API key that gets passed through on every request.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read WorkOS's article on enterprise auth for MCP servers

Context

MCP server authentication is an identity governance problem because the protocol sits between users, AI agents, tools, and downstream APIs. When teams choose API keys for convenience, they often extend standing access into environments that were designed for more controlled authorization patterns.

The core issue is not whether authentication can be made to work, but whether it can be made to work without exposing secrets, weakening consent, or losing visibility into who or what invoked a tool. That makes MCP relevant to NHI governance, workload identity, and the control boundaries IAM teams need to define before adoption scales.

Key questions

Q: How should security teams govern authentication for MCP servers in production?

A: Security teams should treat MCP authentication as an authorization design problem, not just a login problem. The safest pattern is scoped, revocable token use with clear audience and consent boundaries, plus logging that ties each tool call back to an identity and purpose. Reusable API keys should be reserved, if at all, for tightly bounded internal use cases.

Q: Why do API keys create more risk in MCP environments than in ordinary app integrations?

A: API keys create standing access, and standing access is hard to justify when AI tools can call APIs repeatedly on behalf of users. In MCP, a leaked or overbroad key can reach multiple tools, sensitive data sets, or administrative actions. The problem is not just theft. It is the persistence of privilege with little built-in scoping.

Q: When should organisations prioritise OAuth over simpler authentication for MCP?

A: Organisations should prioritise OAuth when an MCP server can touch user-specific data, production systems, or privileged actions. OAuth is more operationally complex, but it gives the team consent, revocation, and scope controls that simple authentication methods usually lack. That matters as soon as the server becomes part of the enterprise identity boundary.

Q: What do security teams need to verify before exposing an MCP server to users?

A: Teams need to verify who can register as a client, what scopes they can request, how tokens are validated, and how consent maps to real tool permissions. If any of those links are vague, the MCP server can expand access beyond the user’s intent or the organisation’s policy. Auditability should be built in before go-live.

Technical breakdown

OAuth bridging for MCP servers

An OAuth bridge sits between the MCP client and the application’s existing identity system, translating user login and consent into tokens the MCP server can validate. In practice, that avoids rebuilding the full OAuth stack inside every MCP deployment, including dynamic client registration, consent handling, and token issuance. The architectural shift is that the MCP server no longer needs direct knowledge of each downstream credentialing step. Instead, it trusts a dedicated authorization layer to assert identity and scope. That lowers implementation burden, but it also concentrates trust in the bridge and makes token validation, audience restrictions, and consent boundaries non-negotiable.

Practical implication: define the bridge as a governed trust boundary and verify token audience, scope, and expiry before any tool execution.

Why API keys are a poor default for MCP access

API keys create standing, reusable access that is easy to pass through but hard to govern. In an MCP context, the key can be exposed to the client, the model, or configuration files, which turns a convenience mechanism into a persistent secret distribution problem. Unlike scoped OAuth tokens, API keys rarely encode user context, consent, or task boundaries well enough for fine-grained access decisions. That makes them especially weak when an MCP server touches sensitive APIs or supports broad user actions. The architectural failure is not just theft risk. It is the absence of per-request identity semantics and revocation discipline.

Practical implication: replace pass-through API keys with scoped, revocable tokens wherever an MCP server handles sensitive or user-specific operations.

Dynamic client registration and consent flow risk

MCP implementations often need OAuth features that ordinary app login flows do not cover, especially dynamic client registration and consent orchestration. DCR lets clients register at runtime, which is useful for flexible integrations but risky if the registration surface is not tightly constrained. Consent flows add another control point, because the system must align what the user approved with what the MCP server can actually do. If either step is loosely implemented, the server can end up with broader access than intended or with tokens that outlive the user’s immediate intent. The mechanism works only when registration, consent, and token verification are treated as one policy chain.

Practical implication: test DCR and consent as a single authorization workflow, not as separate features, before exposing MCP endpoints to production users.

Threat narrative

Attacker objective: The attacker or misused agent gains durable, overbroad access to downstream tools and data through the MCP trust path.

1. Entry occurs when an MCP server accepts a reusable API key or poorly constrained OAuth client registration as the access path into sensitive tools and data.
2. Credential access or abuse follows when the secret, token, or consent boundary is passed through the client or stored in configuration without sufficient scoping.
3. Impact arrives when the agent can call broader APIs, manage user-facing actions, or access data beyond the intended task boundary.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing credential exposure is the wrong default for MCP governance: The article shows that many MCP deployments still rely on API keys passed through every request, which turns access into a reusable secret rather than a governed authorization event. That is not just a weakness in secret handling. It is a control model that assumes the client can safely carry standing privilege across the entire tool path. Practitioners should treat pass-through keys as a design smell, not a normal integration choice.

OAuth bridge architecture changes the trust boundary, not the governance burden: Moving OAuth complexity into a bridge centralises token issuance and consent, but it does not remove the need to govern scope, audience, and revocation. The bridge becomes part of the identity perimeter for NHI-style tool access, so policy drift there becomes policy drift everywhere downstream. Teams should review the bridge as an authorization control point, not as a convenience layer.

Dynamic client registration is a named governance concept for MCP: MCP registration drift: when runtime client registration expands the set of trusted callers faster than identity governance can review them. That matters because flexible onboarding can quietly outpace consent controls, especially in environments where AI agents and external tools are added quickly. The practitioner takeaway is that registration flexibility must be measured against the rate at which access can actually be governed.

MCP servers expose a classic NHI assumption gap: The access model was designed for credentials that remain stable long enough to be reviewed, rotated, and revoked. That assumption fails when the MCP client, model, or integration layer can initiate tool use repeatedly through persistent tokens and broad consent paths. The implication is that IAM teams need to rethink where the authority boundary sits between user identity, machine identity, and tool invocation.

Tool permissions need scoping before scale, not after adoption: WorkOS’ framing shows that developers often prioritise speed over authorization design, but MCP deployments that lack scoping expand blast radius the moment they connect to real data and real actions. This is where NHI governance, zero trust thinking, and application authorization converge. Practitioners should classify every tool as a privilege-bearing capability, not a convenience endpoint.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 48% of organisations say they cannot track and audit the data their AI agents access, leaving a complete compliance and investigation blind spot in nearly half of deployments.
• For the broader control picture, see OWASP Agentic AI Top 10 for the agentic risk model that helps teams separate tool access from runtime authority.

What this signals

MCP authentication is becoming an identity perimeter issue rather than a developer convenience issue. As soon as a server can act on behalf of a user, it inherits governance expectations around scope, consent, and revocation. Teams that treat MCP as just another integration layer will miss the fact that token handling and tool permissions now sit on the same boundary as workload identity.

MCP registration drift: runtime client onboarding can outpace review, which means the organisation may end up with more trusted callers than anyone can inventory. That makes registration controls, not just token controls, a forward-looking governance requirement for programmes that expect AI tool ecosystems to expand.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, per The State of MCP Server Security 2025, the pattern is already operational, not theoretical. Security leaders should assume MCP secrets will be treated as ordinary configuration unless policy, detection, and developer workflow controls change first.

For practitioners

• Eliminate pass-through API keys for production MCP flows Use scoped OAuth tokens or delegated authorization patterns for any MCP server that touches user data, admin actions, or internal APIs. Treat any request path that depends on a reusable secret as a standing-access design that needs replacement.
• Review dynamic client registration as a privileged onboarding process Constrain which clients can register, what metadata they can present, and which scopes they can request. Pair runtime registration with approval gates, audit logging, and explicit ownership so new MCP clients do not appear faster than governance can track them.
• Separate consent from capability expansion Validate that the permissions granted during OAuth consent match the actual tool actions exposed by the MCP server. Re-check scope mappings whenever a new endpoint, workflow, or downstream API is added, because consent drift is a common way privilege grows quietly.
• Treat token validation as a policy control, not a formality Verify audience, expiry, issuer, and task-specific scope before the server executes any tool call. If the token does not clearly bind the user, the client, and the action, the server should fail closed rather than infer intent.

Key takeaways

• MCP server auth is really about who gets to invoke tools, under what scope, and with what revocation discipline.
• Reusable API keys and loosely governed OAuth paths both create standing-access risk when agents can call sensitive APIs at runtime.
• Teams should govern MCP as part of NHI and workload identity strategy, with scoping, consent, token validation, and registration controls tied together.

Key terms

• OAuth bridge: An OAuth bridge is an intermediary layer that connects an application or server to an existing identity system without rebuilding the full authorization flow. In MCP environments, it translates login, consent, and token issuance into a controlled path that the server can validate for scope and audience.
• Dynamic client registration: Dynamic client registration is the runtime process by which a client application registers itself for OAuth access instead of being manually provisioned ahead of time. In MCP, it enables flexible onboarding, but it also increases governance pressure because trusted callers can expand quickly if registration is not tightly controlled.
• Standing access: Standing access is privilege that persists until someone removes it, rather than being created only for a specific task. For MCP servers, standing access usually appears as reusable API keys or long-lived tokens, and it increases risk because access can be passed around, reused, and forgotten.
• Consent boundary: A consent boundary is the line between what a user explicitly approved and what a system is actually allowed to do. In MCP and other tool-connected identity flows, that boundary must stay aligned with real tool permissions, or the platform can drift into overbroad access that users never intended.

Deepen your knowledge

MCP server authentication and authorization are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building tool-connected AI systems or governing secrets across integration layers, it is worth exploring.

This post draws on content published by WorkOS: How WorkOS solved enterprise auth for MCP servers. Read the original.