TL;DR: MCP servers still rely on the implementer to decide how users authenticate, issue tokens, and validate access, and WorkOS outlines three common paths: build OAuth yourself, bridge existing users, or fully host the flow with AuthKit. That choice is an identity design decision, not just an integration detail, because it determines who owns trust, token validation, and lifecycle control.
At a glance
What this is: This article explains three ways to add OAuth to an MCP server and shows that the real decision is who owns authentication, tokens, and lifecycle control.
Why it matters: It matters because IAM teams must decide whether MCP access sits inside existing identity governance or creates a new trust boundary for users, clients, and tokens.
Context
MCP servers expose a governance gap when the protocol defines how tools connect but leaves authentication and authorisation decisions to the implementer. In practice, that means identity teams must decide whether MCP access is a new application boundary, an extension of existing login policy, or a fully delegated OAuth stack.
The article is about OAuth for MCP servers, but the deeper issue is control ownership. If the implementer builds OAuth, bridges existing users, or delegates the flow to a hosted provider, the organisation is choosing who issues tokens, who validates them, and who carries the lifecycle burden for revocation and scope changes.
That makes the topic relevant to NHI governance as much as human IAM, because MCP clients, server endpoints, and token verification create a machine-mediated access path that needs explicit policy, not assumed defaults.
Key questions
Q: What breaks when MCP OAuth is implemented independently by each team?
A: Coverage fragments, redirect handling becomes inconsistent, token validation drifts, and security teams lose visibility into which servers exist or what they can call. The result is shadow MCP: systems that appear to work but cannot be governed as a single identity estate.
Q: Why do dynamic MCP clients increase security risk even when OAuth is used correctly?
A: OAuth only answers how a client authenticates after registration. If the registration step is open, an attacker can still create clients, request scopes and interact with tools before downstream controls have enough context to distinguish legitimate use from abuse.
Q: What signs show that an MCP OAuth implementation is becoming hard to govern?
A: Common signals include separate teams owning login, token issuance, and resource validation; inconsistent scope naming; ad hoc client registration; and no clear revocation path for compromised clients or users. When those controls are fragmented, the MCP server may still function, but identity assurance becomes difficult to audit and change safely.
Q: Should organisations build their own OAuth server for MCP or use a hosted flow?
A: The right choice depends on governance maturity, not preference. Teams with strong OAuth expertise and full lifecycle ownership can justify building and maintaining their own flow. Teams that want to reduce operational burden may prefer a hosted or bridged model, but they still need clear control over scopes, validation, and offboarding.
Technical breakdown
OAuth flow ownership in MCP server design
An MCP server can authenticate users in three materially different ways: run its own OAuth 2.0 authorisation server, bridge an existing user store into an OAuth layer, or delegate the entire flow to a hosted identity service. The important technical distinction is not branding but control placement. In the first model, the organisation owns client registration, consent, token issuance, JWKS publishing, revocation, and key rotation. In the second, it keeps its own login system but still depends on external token handling. In the third, authentication and token lifecycle move outside the app boundary. That changes where trust is established and where failures are investigated.
Practical implication: Define which team owns the authorisation server, token validation, and signing keys before MCP goes into production.
Token validation and discovery for MCP clients
MCP clients rely on OAuth metadata to discover where to authenticate and how to verify tokens. That usually means a protected resource metadata endpoint, a JWKS URI, and a correct issuer and audience check on every request. If those elements are inconsistent, clients may fail open, fail closed, or accept tokens from the wrong trust domain. The article also points to PKCE, redirect URI validation, and short-lived authorisation codes as core mechanics of the OAuth Code Flow. For identity teams, the key architectural point is that MCP interoperability depends on strict token verification, not just successful login UX.
Practical implication: Treat MCP token verification as a protocol control surface, not an application convenience feature.
Why OAuth for MCP creates lifecycle and trust-boundary issues
The protocol makes it easy to connect tools, but not easy to govern who can later revoke access, rotate signing keys, or change scopes when a user leaves or a client is compromised. That is why OAuth for MCP is partly an identity lifecycle problem. The server may be dealing with humans at login time, but the access path is mediated by clients, service endpoints, and signed tokens that outlive the session that created them. In governance terms, the trust boundary spans user identity, application identity, and machine-to-machine access.
Practical implication: Map MCP access to lifecycle controls for users, clients, and tokens instead of treating it as a one-off integration.
Threat narrative
Attacker objective: Obtain valid MCP access tokens or exploit weak OAuth handling to reach protected tools and data through a trusted client path.
- Entry occurs through an MCP client starting an OAuth flow against the server's chosen authorisation path, which may be self-hosted, bridged, or fully hosted.
- Credential access happens when the server issues an authorisation code or access token that becomes the bearer credential for subsequent MCP requests.
- Escalation occurs if redirect URIs, client registration, issuer checks, or token validation are misconfigured, allowing a client to present unauthorised access as legitimate.
- Impact is unauthorised MCP server access through trusted tokens, which can expose internal tools, data sources, or downstream actions the server can perform.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MCP authentication is a governance decision before it is a coding task. The article makes clear that the protocol leaves authentication undefined, so the implementer decides where trust starts and ends. That means identity architecture, not just application engineering, determines whether token issuance, client registration, and revocation stay inside existing IAM controls or become a separate trust domain. The practitioner implication is to classify MCP access as a governed identity integration, not an incidental feature.
OAuth for MCP creates a mixed human-and-machine trust chain that conventional app login thinking misses. A user may authenticate once, but the resulting bearer token is consumed by an MCP client and enforced by the server through JWKS and issuer checks. That separates the person from the credential-bearing actor in a way many access reviews do not model well. The implication is that identity teams need control ownership across the user, the client, and the token, not just the login screen.
Long-lived assumptions about stable access do not hold cleanly in MCP deployments. The trust boundary shifts from browser session to API-style token usage, which makes scope management, revocation, and signing-key rotation part of the access model rather than back-office hygiene. This is where NHI governance enters the picture: the token behaves as a non-human credential even when the user behind it is human. Practitioners should treat the MCP authorization path as identity infrastructure with its own lifecycle.
Identity teams should expect MCP to accelerate the move from integrated auth to delegated auth. The three models in the article reflect a broader market pattern: teams either own more of the identity stack than they intended, or they outsource more than they used to. That widens the gap between application teams shipping MCP capabilities and security teams responsible for assurance. The implication is that governance frameworks must be ready for tool access that is dynamically discovered and token-mediated.
OAuth and MCP now intersect at a point where protocol correctness becomes operational risk. The article's emphasis on protected resource metadata, JWKS discovery, and bearer challenges shows that small implementation errors can alter who is considered authorised. In practice, the weakest control is often not the login system but the token validation path after login. Practitioners should review this as an authorisation architecture problem, not merely an authentication integration.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
OAuth for MCP pushes identity teams toward protocol-level governance, not just application integration. The hard part is no longer adding login, but deciding which team owns the authorization server, the metadata endpoint, and token revocation across the MCP trust chain. That makes MCP a useful test of whether your identity programme can govern machine-mediated access without hand-waving.
Protected resource metadata becomes the operational hinge for MCP interoperability. When clients discover authorization servers dynamically, the quality of issuer, JWKS, and bearer challenge handling determines whether access is predictable or fragile. For practitioners, this means OAuth metadata should be treated as part of the security control plane, not developer convenience.
For practitioners
- Define the MCP trust boundary Document which system owns user authentication, which system issues tokens, and which system validates them before exposing an MCP server to production.
- Enforce strict OAuth metadata checks Require exact issuer, audience, redirect URI, JWKS, and protected resource metadata validation for every MCP client path.
- Separate user identity from client authority Review whether the user account, MCP client, and bearer token each have distinct lifecycle and revocation handling.
- Treat OAuth scopes as service boundaries Limit scopes to the minimum tool surface needed and avoid broad default access for MCP clients that self-register.
Key takeaways
- MCP servers force an explicit decision about who owns authentication, token issuance, and validation, which makes OAuth a governance issue rather than a wiring exercise.
- Bearer tokens, discovery metadata, and redirect handling are the main control points, so small protocol mistakes can undermine a technically working login flow.
- Identity teams should map MCP access to lifecycle, scope, and revocation controls before the server is exposed to users or clients.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on how MCP servers authenticate users and clients through OAuth. |
| NHI-05 — Overprivileged NHI | MCP tokens and clients can easily exceed the minimum access they need if scopes are broad. | |
| Recommendation — Harden MCP authentication paths to prevent weak or misbound OAuth flows from issuing trusted tokens. Limit MCP scopes and client privileges to the smallest usable access surface. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token handling, rotation, and revocation are central to the OAuth design choices discussed. |
| Recommendation — Apply authenticator lifecycle controls to OAuth tokens, signing keys, and revocation processes. | ||
| NIST Zero Trust (SP 800-207) | Principle of least privilege — Least privilege | MCP access should be constrained by the trust boundary and verified on each request. |
| Recommendation — Verify MCP requests continuously and restrict each client to the minimum authorised resource set. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about who is authorised to access MCP resources and how that is enforced. |
| Recommendation — Define and enforce MCP access permissions, entitlements, and authorizations before deployment. | ||
Key terms
- MCP Protected Resource Metadata: A discovery document that tells clients how to find an MCP server's authorization servers, resource identifier, and token verification details. It turns authentication into a machine-readable contract, which is helpful for interoperability but also creates a control point that must be validated carefully.
- OAuth Authorization Code Flow: An OAuth pattern that exchanges a temporary code for tokens instead of sending tokens directly through the browser redirect. The design reduces exposure during the authentication step and is widely used because it separates the front-channel interaction from token issuance.
- 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.
- Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org