SSO & SCIM for MCP: Enterprise Identity at Scale
If your organization is connecting Claude, ChatGPT, or Cursor to internal MCP servers, one question surfaces fast: whose access controls this, and who is accountable when something goes wrong? MCP has no built-in answer. Left alone, teams end up managing access through shared tokens pasted into config files, with no reliable way to revoke one person’s access without breaking everyone else’s, and no way to tell an auditor which employee’s session touched a given record.
This guide is for platform engineers, identity architects, and IT admins standing up MCP for their organization, particularly in regulated industries where DORA, HIPAA, or GDPR auditors will eventually ask who accessed what. It covers how to route MCP sign-in through an existing OIDC identity provider, how to keep user and team membership in sync automatically through SCIM, which identity providers actually support each half of that (they are not the same list), and what changes once every AI tool call is attributed to a named person instead of a shared credential.
Key Takeaways
- MCP Manager federates sign-in from any OIDC-compliant identity provider, including Okta, Microsoft Entra ID, Google Workspace, and Keycloak. The connection is brokered through Auth0 and enabled as an assisted onboarding step, not from a settings screen.
- SCIM 2.0 provisioning creates, updates, and deactivates users from your directory. Deactivation is a soft deactivation, so past log entries still name the person who made each call.
- Per-user identity replaces shared service accounts on the gateway-to-server hop, so each tool call carries the caller’s own credential and is logged with their name, email, and user ID.
- Group sync pushes IdP groups into MCP Manager, where you map each one to a team. Teams grant access to gateways, and each gateway carries its own rules and tool provisioning.
- Every AI client connects through one gateway URL, whether that client is Claude, Cursor, ChatGPT, VS Code, or a headless agent using an API token.
Why MCP Needs Enterprise Identity
The protocol has closed part of the identity gap on its own, but not the part that matters for running MCP across an organization. Here’s what’s actually covered now, what’s still missing, and why the difference isn’t academic once a regulator asks who did what.
What the Protocol Now Covers
MCP is not identity-silent, and has not been for some time. The 2026-07-28 revision treats an MCP server as an OAuth 2.1 resource server. Servers publish Protected Resource Metadata (RFC 9728) so clients can discover the right authorization server. Clients send the RFC 8707 resource parameter so a token is bound to the one server it was minted for, and must validate a returned RFC 9207 iss value before redeeming an authorization code. Dynamic Client Registration is now deprecated in favor of Client ID Metadata Documents.
What It Still Leaves Out
What the spec leaves out is everything above a single client-and-server pair. There is no user directory, no group model, no role assignment, no joiner-mover-leaver lifecycle, and no audit trail spanning more than one server. The same revision also made the protocol stateless: the initialize handshake and the Mcp-Session-Id header are gone, and each request carries its own protocol version and client capabilities in _meta. With no session to anchor context, authority travels per request inside a bearer token, so whatever mints and revokes those tokens becomes the control point.
Without one, teams fill the gap the cheapest way available: a long-lived token pasted into an mcp.json file on a laptop, copied between machines, and attributable to nobody.
Why This Is Concrete for Regulated Organizations
For regulated organizations the gap is concrete. The DORA regulatory technical standards on ICT risk management, Commission Delegated Regulation (EU) 2024/1774, require identity management policies assigning a unique identity and unique user account to each staff member (Article 20), and require events related to access control and identity management to be logged (Article 12). A token shared by a team satisfies neither.
How to Bring MCP Under Your Existing SSO
Connecting MCP to your company’s SSO is one federation, not a per-server integration effort.
Step 1: Connect Your Identity Provider
MCP Manager does not implement OIDC or SAML endpoints itself. It brokers enterprise SSO through Auth0: your IdP is added as an OIDC enterprise connection, and each sign-in is routed by a verified email domain. You supply the issuer URL ending in /.well-known/openid-configuration, the client ID, the client secret value, and the email domains that should route through your IdP. The MCP Manager team completes the connection.
Two behaviors are worth planning around. A federated identity is accepted only when your IdP asserts email_verified, which stops anyone claiming an account on a domain they do not control. And enabling SSO for one domain does not disable other sign-in methods elsewhere, so you can deliberately keep a break-glass administrator account on an unregistered domain.
Note what SSO covers. It authenticates the first of two separate authentications: client to gateway. The second hop, gateway to each upstream MCP server, is brokered separately with a credential scoped to that server. SSO gets a person into the gateway. It says nothing about whether the call the MCP gateway then makes to GitHub or Snowflake should run as that person.
Step 2: Map IdP Groups to MCP Manager Teams
First sign-in creates an account just in time, but that account grants nothing. Access is the intersection of two things:
- A role, which is a bundle of capabilities and which every user holds exactly one of
- Team membership, which decides which gateways a person can reach.
A user on no team can sign in and will see no gateways at all.
Group sync closes that. You push the IdP groups you want represented, then map each to a team on the SSO/SCIM settings page, either by creating matching teams automatically or by consolidating onto existing ones. Mapping is a deliberate step you repeat as you push new groups. Roles are not synced: a provisioned user is created with your workspace default role, and roles are changed inside MCP Manager.
Policy differences between groups are expressed through gateways rather than teams directly. Gateway rules for PII and prompt injection, and feature provisioning deciding which tools, resources, and prompts are exposed, are configured per gateway. Build one gateway per access profile, provision it to the right team, and the group inherits the policy.
Step 3: Set the Gateway URL in Your AI Clients
Every AI client points at one gateway URL. The user adds the gateway in their client, authorizes in the browser, brings an identity for each per-user server, and is done. Headless agents use an API access token scoped to a gateway connection instead of the browser flow.
Making the gateway the only path is an endpoint and client-layer job. Team and enterprise tiers of Claude, ChatGPT, and Cursor let administrators restrict which connectors users may add. Allow only your gateway URL and nobody can wire an arbitrary MCP server into that client. Reinforce with MDM or EDR on managed devices, and use MCP Manager’s static egress IPs so sensitive upstreams accept traffic only from the gateway.
How to Auto-Provision and Deprovision Agent Access with SCIM
SSO handles authentication. SCIM handles the lifecycle.
What SCIM Does for MCP Access
MCP Manager is a SCIM 2.0 service provider, implementing RFC 7643 and RFC 7644 with the standard ServiceProviderConfig, ResourceTypes, and Schemas discovery endpoints. Your IdP is the client, pushing create, update, and deactivate operations to an endpoint hosted for your workspace and authenticated with a workspace-specific bearer token.
Your directory becomes the source of truth. Fields and memberships that SCIM manages are locked in the MCP Manager UI. An administrator can add someone to a SCIM-managed team for immediate access, but the next push reconciles membership back to what the IdP says.
The deprovision side matters more, and its design is deliberate. Deactivation is a soft deactivation: the account is marked inactive and workspace membership ends, but the user record is retained so every logged action keeps pointing at the real person. Reactivating in your IdP restores the account and reapplies group-derived team membership. SCIM also only deprovisions the users it manages, so manually created accounts and accounts on other domains still need removing by hand.
Setting Up SCIM
SCIM is enabled for your workspace as an assisted step, then connected from your side:
- Add a SCIM 2.0 application in your IdP that authenticates with an OAuth bearer token, and hide it from users. It is a provisioning connector, not a sign-in tile.
- Receive the SCIM base URL and bearer token, delivered through a time-limited secure link.
- Paste both into the application’s provisioning settings, uncheck Import Groups, and run your IdP’s connector test.
- Enable Create Users, Update User Attributes, and Deactivate Users.
- Assign groups on the Assignments tab, push them on Push Groups, then map each pushed group to a team.
Sign-in and provisioning are two separate applications in your IdP, each with its own assignment list. A user can be provisioned and still unable to sign in if they were never assigned to the OIDC application, which is the most common cause of an authentication failure after the IdP returns the user.
Which Identity Providers Does an MCP Gateway Support?
Compatibility is standards-based rather than a certified vendor list, and the two capabilities are worth separating.
SSO needs a standard OIDC provider built on OAuth 2.0 or 2.1, ideally with discovery at /.well-known/openid-configuration, supporting the authorization code flow with PKCE and returning an ID token carrying email and email_verified. That surface is near-universal. SAML is not a supported path.
SCIM needs your IdP to act as an outbound SCIM client. This is where the list narrows, because many platforms implement SCIM only inbound, as a target for an upstream IdP. Being a SCIM target does not let a provider push to MCP Manager.
The split produces results teams do not always expect. Okta and Microsoft Entra ID support both, subject to licensing: outbound SCIM to a custom app needs Okta Lifecycle Management, and provisioning a non-gallery SCIM app needs Entra ID P1 or higher. Google Workspace and Keycloak are supported for SSO but are not documented SCIM paths, because Google’s auto-provisioning is catalog-gated and Keycloak ships no outbound SCIM client. AWS IAM Identity Center, Auth0, and Salesforce Identity are likewise SSO-only here. PingOne, PingFederate, OneLogin, JumpCloud, authentik, and IBM Security Verify are among those marked for both.
Not sure your provider is covered? The full supported identity providers list covers more than forty options with the edition caveats that apply.
What Per-User Identity Changes About MCP Governance
Per-user identity turns MCP governance from a network control into an accountability system: every tool call, whether it reads or writes, resolves to one named person’s credentials, one entry in the audit log, and one set of permissions that can be revoked without touching anyone else’s access.
Audit Trails That Name a Person
The identity scheme is set per server on a gateway, not per gateway. Under a per-user scheme, each person authenticates to that server as themselves, the downstream system enforces their own permissions, and the log records user_name, user_email, and user_guid alongside the server, tool, and identity used. A shared scheme uses one service account for everyone and is the right choice only where the downstream system has no per-user concept.
Re-authentication preserves attribution by design. Identities are write-once: repairing a broken credential mints a new identity and migrates its gateway assignments and live connections across, rather than mutating the old one. A user might reauthorize as a different provider account, and overwriting in place would change who past log entries appear to name.
Least-Privilege Enforcement That Actually Works
A common assumption is that an agent acting with a user’s own credentials is safe, because the person already has that access. The scope of use is different. A person opens a few folders. An agent enumerates everything in scope at machine speed and puts the results into a model’s context.
Per-user identity is therefore the floor, not the ceiling. Feature provisioning fails closed, exposing only allowlisted tools, resources, and prompts. A useful pattern falls out of the two controls together: add the same server to a gateway twice, once with a shared identity exposing read and search tools, and again with a per-user requirement for the write tools. Reads stay frictionless, and every write carries individual accountability.
Compliance Readiness for DORA, HIPAA, and GDPR
The DORA RTS requires a unique identity per staff member and the logging of identity and access-control events. The HIPAA Security Rule requires unique user identification (45 CFR 164.312(a)(2)(i)) and audit controls recording activity in systems holding electronic protected health information (164.312(b)). Under the GDPR, answering a data subject request depends on establishing which systems processed a person’s data and on whose authority. Each obligation is stated in terms of an identifiable user, which a shared credential cannot produce.
Rollout Levers Worth Getting Right Early
These five choices determine whether the identity layer holds up as more teams and gateways get added, or turns into its own maintenance burden.
- Start with one team, then expand. Validate group mapping, provisioning, and rules on a single pilot gateway before rolling out organization-wide.
- Keep one administrator outside SSO. Because routing is by email domain, any domain you do not register keeps the standard email-code login. That account is the recovery path if the IdP connection breaks or a client secret expires.
- Use group sync instead of manual team assignment. Manual additions to a SCIM-managed team are overwritten on the next push, so treat them as temporary access only.
- Separate gateways where policy differs. Rules and tool provisioning are per gateway. Two teams with different risk profiles need two gateways, not one gateway with two team assignments.
- Export logs to your SIEM, and check what leaves. MCP Manager forwards logs and traces over OTLP/HTTP to any OpenTelemetry collector, one collector per organization. Forwarded records are not filtered by your gateway rules, so use the Export content setting if payloads should not leave.
Conclusion: Identity Is the Foundation for Governed MCP
SSO and SCIM are not features you add to an MCP deployment later. They are what makes the rest of the stack meaningful. Rules without identity tell you a call was blocked but not whose. Audit logs without identity record a service account. Least privilege without identity has no subject to be least-privileged about.
MCP Manager by Usercentrics federates your existing IdP, provisions users and teams through SCIM 2.0, and brokers per-user identity to every upstream server through a single gateway URL.
For teams still weighing whether to formalize identity now or later, the honest answer is that it gets harder to retrofit the longer shared tokens stay in circulation. The sooner every call resolves to a name, the smaller that cleanup job stays.
FAQ
How do I bring MCP under our existing SSO?
Provide your OIDC issuer URL, client ID, client secret value, and the email domains to route, and allow the sign-in redirect URLs in your IdP application. Setup is assisted rather than self-serve. Once live, users entering a registered work email are routed to your IdP.
How do I auto-provision and deprovision agent access with SCIM?
Add a SCIM 2.0 application in your IdP, paste the SCIM base URL and bearer token issued for your workspace, enable Create, Update, and Deactivate, then assign users and push the groups you want mapped to teams.
Which identity providers does MCP Manager support?
Any provider issuing OIDC ID tokens with a verified email claim works for SSO. Provisioning additionally requires outbound SCIM 2.0 with a bearer token, which excludes providers implementing SCIM only as a target.
Does MCP Manager support just-in-time provisioning?
Yes for accounts. A user on a registered SSO domain who has never been provisioned is created on first sign-in from the verified identity. That account has no team membership, and therefore no gateway access, until SCIM or an administrator places them on a team.
Can I set different access policies for different teams?
Yes, by scoping policy to gateways. Rules, tool provisioning, and per-server identity schemes are configured on a gateway, and each gateway is provisioned to the teams that should reach it.
What happens if someone bypasses the gateway and connects to an MCP server directly?
SSO alone does not prevent it. Restrict connectors to the gateway URL in your AI clients’ admin settings, reinforce with MDM or EDR on managed devices, and use static egress IPs so sensitive upstreams accept gateway traffic only.
Does per-user identity work for both local and remote MCP servers?
Yes. Remote servers connect over HTTPS. A server running on a laptop is registered as a workstation server: a containerized tunnel agent opens an outbound WireGuard-based tunnel, a local router validates each request with an access key, and the same identity model, rules, and logging apply.
How does SCIM provisioning for MCP differ from other SaaS applications?
The protocol mechanics are the same. What differs is the consequence: group membership decides which gateways, and therefore which MCP servers, tools, and rules, apply to that user. Bulk operations, sorting, ETag concurrency, and complex filters are not supported, and list pages are capped at 500 records.
