The safest pattern is to make the enterprise IdP the authorization server and keep the MCP server as a resource server. The IdP should authenticate users or agents, issue tokens, enforce MFA and session policy, and maintain audit trails. The MCP server should only validate tokens, map claims to permissions, and serve data. That separation keeps credential issuance centralized and reduces auth logic risk.
Why the IdP Should Stay the Authorization Server
In an MCP integration, the cleanest design is to let the enterprise identity provider own authentication, token issuance, MFA, session policy, and audit trails, while the MCP server stays focused on resource access. That keeps the protocol boundary clear: the server should trust token validation and claim interpretation, not recreate user authentication, consent, or policy logic inside the tool endpoint.
This separation matters because the MCP server is the place where business data and tool actions are exposed, not the best place to re-implement enterprise login. If the server starts minting its own credentials or making ad hoc identity decisions, you fragment policy, weaken revocation, and make incident review harder because the authoritative identity record no longer lives in one place.
The model also fits the MCP authorization pattern described in the Model Context Protocol: Authorization specification: the resource server should rely on OAuth-style delegation rather than becoming a mini identity provider.
What the MCP Server Should and Should Not Do
An MCP server should validate that a presented token is genuine, check that the audience and scopes match the tool or resource being requested, and map approved claims to local permissions. It should also reject tokens that are expired, incorrectly scoped, or issued for a different resource, because those checks preserve the trust boundary between the enterprise IdP and the server.
What it should not do is issue its own user credentials, run a parallel MFA flow, store long-lived login state for humans, or invent a separate approval process that bypasses enterprise policy. Once the MCP server begins acting like an identity broker, you get duplicated session handling, inconsistent revocation, and a higher chance that different tools will interpret the same identity differently.
For a practical reference on this split, teams can use the MCP Gateway and MCP Server Governance Guide to align gateway design, client allowlists, and token passthrough with the enterprise control plane.
Where Teams Usually Go Wrong
The most common failure is to let the MCP server accumulate identity logic because it feels simpler during early development. That shortcut usually appears as local token minting, custom session cookies, duplicated consent screens, or server-side user stores that slowly drift away from the enterprise directory and conditional-access rules.
Another recurring mistake is treating “accepting a token” as the same thing as “enforcing policy.” A valid token does not automatically mean the request is safe for every tool. The server still needs explicit authorization checks, but those checks should be constrained to resource access and not expanded into identity lifecycle management.
Teams that are building this pattern should compare the design against the Identity Provider and SSO Security Guide and the IAM and Identity Provider Buyer’s Guide when they need to confirm that the IdP, not the MCP server, remains the policy authority.
Risk and Threat Considerations
When an MCP server starts behaving like a separate identity layer, the security risk is not just duplicated configuration. It creates a second place where tokens, sessions, and permissions can be mishandled, which increases the chance of overprivilege, weak revocation, and inconsistent audit evidence across tools and environments.
Failure mechanism: The server accepts identity decisions outside the enterprise IdP, such as locally issued credentials, ad hoc session state, or custom scope interpretation, so policy becomes fragmented and hard to enforce consistently.
Impact: A compromise or misconfiguration in the server can turn into broad unauthorized access, delayed revocation, and a confusing incident response path because the authoritative identity trail is split between systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | MCP access depends on enterprise user authentication and centralized identity control. |
| IA-5 — Authenticator Management | The pattern relies on centralized token and credential lifecycle control. | |
| AC-3 — Access Enforcement | The MCP server must enforce claims-to-permission decisions for tools and resources. | |
| Recommendation — Use IA-2 to keep enterprise authentication outside the MCP server. Apply IA-5 to centralize token issuance, rotation, and revocation in the IdP. Use AC-3 to enforce token-derived permissions at the resource server. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication and Access Control | The design separates authentication from resource access across enterprise and MCP layers. |
| GV.OC-01 — Organizational Context | The architecture should keep identity authority aligned to enterprise control ownership. | |
| Recommendation — Define enterprise identity as the source of authentication and access decisions. Assign identity governance to the enterprise control plane, not the MCP server. | ||
| OWASP ASVS | V10 — OAuth and OIDC | The answer centers on using OAuth/OIDC-style delegation rather than custom login logic. |
| Recommendation — Implement OAuth and OIDC flows instead of custom MCP authentication. | ||
Practitioner Guidance
What to verify: Confirm that the enterprise IdP is the only component issuing user or agent tokens, and that the MCP server only performs validation and authorization against those tokens. If the server can mint credentials, refresh sessions, or bypass enterprise MFA, the design has already drifted into mini-IdP territory.
What good looks like: The IdP owns authentication, step-up policy, and audit logs, while the MCP server only consumes claims, enforces least-privilege tool access, and denies requests when the token audience or scope does not match the resource.
Practitioner takeaway: Keep identity decisions centralized and tool authorization local, because the moment the MCP server starts issuing or managing credentials, you lose the control, revocation, and audit consistency that make the design safe.
Related resources from NHI Mgmt Group
- What should teams do when an MCP server must rely on a third-party identity provider?
- How should software teams launch enterprise features without creating identity debt?
- How should security teams implement MCP-based access to both structured and unstructured enterprise data without creating governance gaps?
- How should security teams govern enterprise AI introductions without creating hidden data and identity risk?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org