OAuth for MCP servers: what identity teams need to decide

At a glance

What this is: This is an implementation guide for adding OAuth to an MCP server, with the key finding that the MCP spec leaves authentication and authorization design to the builder.

Why it matters: It matters because IAM, NHI, and autonomous governance teams need to decide where token issuance, validation, and scope control live before MCP becomes another unmanaged access path.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read WorkOS's guide to adding OAuth to an MCP server

Context

MCP server authentication is a governance problem before it is a code problem. The protocol expects the server to know who is making requests and what they are allowed to do, but it does not prescribe how identity, consent, or token handling should be implemented.

That leaves practitioners choosing between direct OAuth ownership, an OAuth bridge, or a hosted identity layer. For NHI and agentic AI programmes, the decision affects where trust is established, how tokens are validated, and how quickly access can be scoped or revoked as MCP usage expands.

Key questions

Q: How should security teams implement OAuth for MCP servers?

A: Start by deciding who owns token issuance, client registration, consent, and revocation, then make the MCP server validate issuer, audience, expiry, and scope on every request. Treat MCP clients as explicit OAuth clients, not generic sessions, and keep discovery endpoints aligned with the intended authorization server. That is the minimum control boundary for secure MCP access.

Q: Why do MCP servers increase identity governance complexity?

A: MCP servers add a new machine-facing access layer that can introduce client sprawl, token sprawl, and unclear ownership if the OAuth model is left vague. Governance gets harder because the server must define trust for both users and the clients acting on their behalf. That makes inventory, scope review, and revocation part of core operations.

Q: What breaks when MCP access is built without lifecycle controls?

A: Access becomes difficult to track, review, and remove, especially when client registration is dynamic or token issuance is delegated to another system. The failure is not only technical. It is governance drift, where active clients and scopes no longer match current business need. That creates lingering access paths and weak accountability.

Q: How should teams decide between self-managed and hosted OAuth for MCP?

A: Choose the model that matches your ability to run token lifecycle, key rotation, and client review continuously. Self-managed OAuth gives maximum control but requires stronger operational discipline. Hosted OAuth reduces implementation burden, but the team still owns scope governance, trust decisions, and access review outcomes. The right choice is the one you can govern reliably.

Technical breakdown

OAuth 2.0 authorization for MCP servers

An MCP server that uses OAuth must still define the full identity boundary around it. That includes client registration, authorization code flow, PKCE for public clients, token issuance, JWKS publication, and validation of issuer, audience, expiry, and scope. The protocol itself does not create authorization logic, so the implementer must decide whether MCP clients are treated like first-party applications, delegated tools, or externally registered integrations. That distinction shapes consent, revocation, and auditability across the entire access path.

Practical implication: map MCP clients to explicit OAuth client policies before exposing any tool or resource endpoint.

Dynamic client registration and protected resource metadata

Dynamic client registration reduces setup friction, but it also expands the number of identities that can appear without direct operator handling. Protected resource metadata lets a client discover the authorization server and JWKS endpoint from a 401 challenge, which improves interoperability but also makes discovery part of the trust model. In practice, the metadata document becomes a machine-readable entry point into the identity stack, so it needs the same governance discipline as any other federation surface. If discovery is loose, onboarding becomes easy for both legitimate and unapproved clients.

Practical implication: control discovery endpoints as production trust surfaces, not convenience features.

Hosted OAuth versus self-managed identity boundaries

A hosted OAuth layer shifts token issuance, consent, and user lifecycle mechanics out of the MCP server, while a self-managed model keeps those responsibilities in-house. The technical difference is not just where login happens. It is where signing keys, revocation logic, user linkage, and scope policy are enforced. For teams running multiple MCP clients, a hosted model can centralise controls, but it also concentrates dependency on the upstream identity boundary. A self-managed model offers maximum control, but only if the team can maintain the same security and operational rigor over time.

Practical implication: choose the model that matches your ability to operate token lifecycle, revocation, and key rotation continuously.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

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

NHI Mgmt Group analysis

OAuth for MCP is now an identity boundary problem, not a feature checkbox. The article makes clear that the MCP spec leaves authentication undecided, which means each server creates its own trust boundary by implementation choice. That matters because identity control is where scope, revocation, and auditability either become enforceable or remain implicit. Practitioners should treat the OAuth design for MCP as part of the access architecture, not as an add-on after integration.

Hard-coded or loosely governed MCP credentials create classic NHI exposure patterns. MCP servers are already showing the same failure modes seen in service-account and token sprawl: exposed secrets, weak scoping, and unclear ownership. The article’s option set can still be implemented badly if tokens are issued without lifecycle discipline. The practical conclusion is that MCP identity needs the same governance baseline as any other non-human access path.

Protected resource metadata turns discovery into a governance surface. When clients discover authorization servers and JWKS endpoints dynamically, the metadata endpoint becomes part of the trust chain. That is useful for interoperability, but it also means an unauthenticated machine-readable endpoint can shape how access is established at runtime. Practitioners should recognise the metadata document as a policy entry point, not just a convenience file.

Managed OAuth can simplify operations, but it does not remove accountability. Whether the MCP server self-hosts OAuth or uses a bridge or hosted flow, someone still owns token policy, client trust, and user linkage. That ownership becomes more visible as MCP moves from one-off integrations to a broader enterprise access layer. The governance question is not who hosts login, but who can prove every issued credential is still appropriate.

Dynamic client registration needs lifecycle controls or it becomes identity sprawl for tools. DCR is operationally attractive for MCP ecosystems, but each self-registering client is another identity that must be tracked, scoped, reviewed, and removed. Without that lifecycle discipline, the registration mechanism accelerates tool onboarding faster than governance can keep up. Practitioners should treat DCR as a governed intake process, not a permanent open door.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to Astrix Security.
• For related agentic risk framing, OWASP Agentic Applications Top 10 helps place MCP trust boundaries in the wider tool-use threat model.

What this signals

Dynamic client registration can accelerate MCP adoption faster than governance can absorb. That is why tool-facing identity needs an inventory, review, and offboarding model before it becomes common across internal platforms. When clients can appear quickly, lifecycle control becomes the differentiator between managed access and tool sprawl. The question is whether your programme can keep pace with the rate of new MCP identities.

MCP sits at the intersection of workload identity and delegated user access, so the control model has to cover both. That is where standards such as OWASP Agentic AI Top 10 become useful, because the same token, scope, and tool-use concerns show up again once models start invoking actions through MCP. Practitioners should expect identity review processes to move closer to runtime behaviour, not just provisioning records.

Access scoping is the named concept practitioners should watch here: if MCP permissions are broad at issue time, the rest of the control stack is compensating after the fact. The operational signal is whether each client and token pair can be tied to a narrow tool set, a clear owner, and a revocation path. If not, MCP becomes another identity surface with familiar NHI failure modes.

For practitioners

• Define the MCP OAuth ownership model Decide whether the server, an identity bridge, or a hosted provider owns authorization codes, token signing, scope policy, and revocation. Document that ownership before exposing any tool endpoint, and keep the decision aligned with how quickly your team can rotate keys and review clients.
• Require explicit client registration for every MCP integration Do not let MCP clients self-appear without review. Tie dynamic client registration to an approval workflow, maintain an inventory of registered clients, and remove unused client IDs when the integration is retired.
• Treat the JWKS and metadata endpoints as trust surfaces Protect /.well-known/oauth-protected-resource and the JWKS endpoint with the same operational oversight you apply to other federation components. Monitor changes, verify issuer consistency, and confirm that clients are discovering only the intended authorization server.
• Scope tokens to tool-level access, not broad user access Limit claims and scopes to the minimum tool set required by the MCP server. Avoid issuing reusable credentials that outlive the task, and make sure the token validation path rejects expired, revoked, or over-scoped access.

Key takeaways

• MCP authentication is an identity architecture decision, not a plug-in setting.
• Dynamic client registration and discovery simplify integration, but they also widen the governance surface if ownership is unclear.
• Teams should decide now who issues, validates, scopes, and retires MCP credentials before the protocol becomes embedded in production workflows.

Key terms

• Mcp Client: A software client that requests tools or data from an MCP server on behalf of a user or workload. In practice, it becomes an identity-bearing integration that needs registration, scope control, and revocation. Treat it like a governed application client, not an anonymous API caller.
• Protected Resource Metadata: A machine-readable document that tells MCP clients where to find the authorization server and related discovery details. It reduces integration friction, but it also becomes part of the trust chain because clients use it to decide where authentication begins. Governance of this endpoint matters.
• Dynamic Client Registration: A mechanism that lets clients register themselves for OAuth access without manual setup for every application. It speeds onboarding, but it also increases identity sprawl if registrations are not reviewed, scoped, and retired with discipline. For MCP environments, it is a lifecycle control as much as a convenience feature.
• JWKS Endpoint: A public key set endpoint used to verify signed tokens issued by an authorization server. For MCP, it anchors token validation and therefore sits directly on the trust boundary. If the issuer or key rotation process is weak, token verification becomes unreliable and access decisions lose integrity.

Deepen your knowledge

OAuth for MCP servers and token lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing machine-facing access paths like this, the course helps translate identity policy into operational control.

This post draws on content published by WorkOS: How to add OAuth to your MCP server. Read the original.