Skip to main content
MCP Manager’s enterprise identity features are standards-based, so compatibility is broad rather than a fixed list of certified vendors. Sign-in is OpenID Connect (OIDC) federated through Auth0, and user provisioning is SCIM 2.0 — both open IETF/OpenID standards that virtually every modern identity provider (IdP) implements. The table below names the providers customers most often ask about and marks, for each, what MCP Manager supports today.
Short answer: if your IdP speaks OIDC and SCIM 2.0, MCP Manager works with it. There is no per-vendor integration code on our side — we federate any OIDC provider and accept SCIM 2.0 from any conformant client. If you don’t see your provider below, that almost certainly means we haven’t listed it yet, not that it is unsupported. Talk to us and we’ll confirm.

How compatibility is determined

Two independent standards decide whether a provider appears with a check mark, and they are worth separating because a provider can support one without the other.

SSO — OpenID Connect (OIDC)

MCP Manager brokers single sign-on through Auth0, which adds your IdP as an OIDC enterprise connection and routes each sign-in by verified email domain. Your IdP only has to do what any OpenID Connect identity provider does:
  • Expose a standard OIDC provider built on OAuth 2.0 / OAuth 2.1, ideally with an OpenID Provider Metadata document at /.well-known/openid-configuration for discovery.
  • Support the Authorization Code flow with PKCE (RFC 7636) and return an ID token (a signed JWT) carrying the email and email_verified claims.
That surface is near-universal, so the SSO (OIDC) column is a check mark for essentially every real identity provider. MCP Manager does not implement SAML endpoints — connections are OIDC. See Single Sign-On (SSO) for the full setup.

SCIM provisioning — SCIM 2.0 (outbound)

MCP Manager is a SCIM 2.0 service provider (the target), implementing the System for Cross-domain Identity Management protocol per RFC 7643 (core schema) and RFC 7644 (protocol), authenticated with an OAuth 2.0 Bearer token (RFC 6750). It exposes the standard /ServiceProviderConfig, /ResourceTypes, and /Schemas discovery endpoints, and reads group membership from both the groups attribute and the Enterprise User extension schema (urn:ietf:params:scim:schemas:extension:enterprise:2.0:User). The distinction that decides the SCIM 2.0 provisioning column is direction:
  • Outbound SCIM (what MCP Manager needs). Your IdP acts as a SCIM client/source, pushing create, update, and deactivate operations to MCP Manager’s endpoint. Only providers that can do this earn a check mark.
  • Inbound SCIM (not sufficient on its own). Many platforms — especially developer-focused CIAM products — implement SCIM only as a service provider that receives provisioning from an upstream IdP. Being a SCIM target does not let a provider push to MCP Manager, so those providers are not marked for SCIM here.
See SCIM Provisioning for the supported operations, filtering, and paging limits.

How to read the table

means MCP Manager supports that capability with this provider. means it is not a documented path today — not a claim that the provider is incompatible. Many cells are simply combinations we have not yet validated or that depend on a provider edition; sign-in may still work even where provisioning is not listed. When in doubt, contact us.

Supported identity providers

Edition and licensing notes

A few providers gate outbound SCIM behind a specific edition or add-on. Where a row above is marked for SCIM, confirm your license covers provisioning before you plan a rollout:
  • Okta — outbound SCIM to a custom app requires the Lifecycle Management add-on.
  • Microsoft Entra ID — provisioning a non-gallery SCIM application requires Entra ID P1 (or P2 / a bundle that includes it).
  • OneLogin — provisioning is a paid capability on the IdP plan.
  • Workday — SCIM is part of the Enterprise tier and requires SSO to be enabled first.
SSO via OIDC generally carries no such gating — it is part of the base offering for nearly every provider listed.

Don’t see your provider?

The table is a convenience, not a boundary. Because MCP Manager federates any OIDC provider and accepts SCIM 2.0 from any conformant client, a provider’s absence here is not a statement that it won’t work.
If your IdP issues OIDC ID tokens with a verified email claim, you can use it for SSO. If it can push outbound SCIM 2.0 with a bearer token, you can use it for provisioning. To confirm your specific provider and edition, use the Contact us prompt on the SSO / SCIM settings page or talk to your MCP Manager contact.

Further reading

Single sign-on (SSO)

How MCP Manager federates your OIDC identity provider through Auth0.

SCIM provisioning

Automatically create users and sync IdP groups to MCP Manager teams.

Authentication & Identity

The two-authentications model and how identity is brokered to servers.

Teams

How team membership grants users access to gateways.

External sources

OpenID Connect Core

The OIDC specification behind MCP Manager’s SSO federation.

SCIM 2.0 — RFC 7644

The SCIM protocol MCP Manager implements as a service provider.

SCIM Core Schema — RFC 7643

The SCIM resource schema for users and groups.

OAuth 2.0 Bearer Token — RFC 6750

The bearer-token scheme that authenticates SCIM requests.