Single Sign-On (SSO)

How MCP Manager brokers enterprise single sign-on through Auth0: how IdP federation and email-domain routing work, what you provide to connect Okta or Entra ID, the direct-login IdP dashboard tile, the end-user sign-in experience, just-in-time provisioning, and keeping a break-glass account.

Single sign-on (SSO) lets your team sign in to MCP Manager with your existing corporate identity provider (IdP) — Okta, Microsoft Entra ID, or any OIDC-compatible IdP (see Supported identity providers) — instead of an MCP Manager-specific credential. MCP Manager brokers enterprise SSO through Auth0: your IdP federates to MCP Manager’s Auth0 tenant, and MCP Manager routes each sign-in based on the user’s verified email domain. The result is one-click access for your people, central control in your IdP, and no separate password for anyone to manage.

Setting up SSO is a guided, assisted process — you do not self-serve it from a settings screen. You provide a few values from your IdP, and the MCP Manager team completes the connection on our side. This page explains what we ask for, what we configure, and exactly what your administrators and end users will experience. To request SSO for your workspace, use the Contact us prompt on the SSO / SCIM settings page or talk to your MCP Manager contact.

How single sign-on works in MCP Manager

MCP Manager does not implement SAML or OIDC endpoints directly. Instead, it uses Auth0 as the identity broker between your corporate IdP and the MCP Manager application. Your IdP is added to MCP Manager’s Auth0 tenant as an enterprise connection, and sign-in is matched to your organization by email domain.

Three properties of this flow matter for planning:

• Domain-based routing. MCP Manager decides whether to send a sign-in through your IdP by matching the part of the email address after the @ against the domains you register for SSO. You tell us which domains route through your IdP (for example, yourcompany.com).
• Verified email required. MCP Manager accepts a federated identity only when your IdP asserts that the email address is verified. A sign-in carrying an unverified email is rejected and returned to the login screen. This prevents anyone from claiming an account on your domain that they do not actually control.
• No forced SSO by default. Enabling SSO for a domain does not, on its own, disable other sign-in methods for addresses outside that domain. Email addresses on domains you have not registered for SSO continue to use the standard email-code login. Use this deliberately to keep a break-glass account (see Keep a break-glass account outside SSO).

What you provide, and what we configure

Connecting your IdP is a short exchange. You create one application in your IdP and send us three values; we register your enterprise connection and enable SSO for the domains you specify.

1. Create an OIDC application in your IdP

   In your IdP (for example, Okta), create a new OIDC — Web Application app integration. This is the application your users will sign in through.

2. Set the sign-in redirect URI we give you

   Add the sign-in redirect (callback) URI for MCP Manager’s Auth0 tenant. We provide the exact value during onboarding, and a separate value if you want to validate in our sandbox first. Paste it verbatim — the redirect URI must match exactly for the connection to succeed.

3. Send us your connection details

   Send your MCP Manager contact the Client ID, the Client Secret (the secret value), and your IdP domain (for example, yourcompany.okta.com). We store the secret encrypted and use these to register your enterprise connection in Auth0.

   The Client Secret is a sensitive credential. Share it through the secure channel we provide, not over email or chat. If a secret is ever exposed, rotate it in your IdP and send us the new value.

4. Tell us which email domains route through SSO

   Confirm the email domain or domains that should sign in through your IdP. We enable SSO for those domains and let you know when the connection is live.

   Once the connection is live, a user on a registered domain who enters their work email at the login page is routed to your IdP to authenticate.

Show MCP Manager on your IdP dashboard (optional)

By default, MCP Manager sign-in is service-provider-initiated: the user starts at MCP Manager, enters their email, and MCP Manager routes them to your IdP. You can also add an MCP Manager tile to your IdP dashboard that signs users in directly — one click takes them straight into MCP Manager through your IdP, with no email to type. This works because the tile points at a sign-in URL that already names your workspace’s connection, so MCP Manager knows which IdP to use without asking.

1. Allow IdP-initiated launch

   In the OIDC application’s general settings, set Login initiated by to allow both the IdP and the app (in Okta, Either Okta or App), and enable Display application icon to users.

2. Set the initiate-login URI to your tenant-scoped sign-in URL

   Set the application’s Initiate login URI to the workspace-specific MCP Manager sign-in URL we provide during onboarding. It has the form:

   https://gateway.mcpmanager.ai/auth/login?tenant=your-workspace-tenant
   

   The tenant value identifies your workspace’s enterprise connection and is specific to your organization — MCP Manager gives you the exact value; do not guess it. Because the URL carries the tenant, clicking the dashboard tile sends the user straight to MCP Manager and through your IdP, signed in without entering their email.

3. Assign the application to your users

   Assign the OIDC application to the users or groups who should see and use the tile.

   The tile only appears for users who are assigned to the OIDC application in your IdP. This is separate from SCIM provisioning assignment — a user assigned for provisioning but not assigned to the OIDC application will not see the tile and cannot launch from it. See SCIM provisioning.

How your team signs in

For end users, signing in with SSO is nearly invisible. They never create or manage an MCP Manager password. There are two entry points:

• From your IdP dashboard. If you configured the tile above, clicking it signs the user straight into MCP Manager — no email entry required.
• From the MCP Manager login page. A user can also start at MCP Manager directly, as below.

1. Go to the MCP Manager login page

   The user opens the login page and enters their work email address.

2. Continue through your IdP

   MCP Manager recognizes the email domain and routes the user to your IdP to authenticate. The login button is currently labeled Send code even for SSO users — clicking it does not send a code to an SSO user; it forwards them to your IdP. Once authenticated there, the IdP returns them to MCP Manager.

3. Land in the workspace

   The user arrives signed in. If this is their first sign-in, MCP Manager creates their account automatically (see First sign-in and access).

Tell users who start from the login page that seeing Send code is expected — entering a registered work email and continuing will route them through your IdP rather than emailing a code. The label is a known rough edge in the shared login form. Users who launch from the IdP dashboard tile never see this prompt.

First sign-in and access

MCP Manager provisions an account the first time a user signs in through SSO — you do not have to pre-create accounts for SSO to work. Understanding what a freshly provisioned user can and cannot do prevents confusion on day one.

• Just-in-time account creation. When a user on a registered domain signs in through your IdP and no MCP Manager account exists yet, MCP Manager creates one from the verified identity (email, first and last name). This happens even if the user was never provisioned through SCIM.
• Access still depends on teams. A just-in-time account, on its own, grants no access to any gateway. In MCP Manager, access to gateways is granted through teams. Until a user is placed on a team — automatically through SCIM group-to-team mapping or manually — they can sign in but will not see any gateways.
• SCIM is the durable path to team access. If you want users to land in the right teams automatically, pair SSO with SCIM provisioning so group membership flows from your IdP into MCP Manager teams. See SCIM provisioning.

Keep a break-glass account outside SSO

Because MCP Manager routes sign-in by email domain, any domain you do not register for SSO keeps using standard email-code login. We strongly recommend keeping at least one administrator account on such a domain.

Register only the domains you want to flow through your IdP, and keep a separate administrator account on an unregistered domain. If your IdP ever has an outage or a misconfiguration, that break-glass account can still sign in and restore access. Routing every domain through SSO removes this safety net.

Who can configure SSO and SCIM mapping

The end-user sign-in flow is open to anyone on a registered domain — it is not gated by a capability. What is gated is the in-app SSO / SCIM settings page, where administrators manage how IdP groups map to MCP Manager teams.

Visibility and access to that page are controlled by the Manage SSO/SCIM mapping capability. When a user’s role has this capability, the SSO / SCIM settings page is available to them; when it does not, the page is hidden and navigating to it returns the user to the People area. Capabilities are assigned per role and are fully configurable — including on any custom roles you create — so access depends on the capabilities granted to a person’s role, not on any fixed role name.

If you expect to see the SSO / SCIM settings page and it is not there, your role does not have the Manage SSO/SCIM mapping capability. Ask a workspace administrator to grant it to your role from People.

Troubleshooting

A user is not routed to the IdP and sees a code prompt instead

MCP Manager routes to your IdP only for email domains registered for SSO. If a user enters an address on an unregistered domain, they get the standard email-code flow. Confirm the user’s email domain is one you registered with us, and that they entered the corporate address rather than a personal one.

Authentication fails after the IdP returns the user

The most common cause is that the user is not assigned to the OIDC application in your IdP. Assign the user (or their group) to the OIDC application and have them try again. Remember that assignment to the OIDC application is separate from SCIM provisioning assignment — a user can be provisioned yet still be unable to sign in if they are not assigned to the OIDC application.

Sign-in is rejected with an unverified-email message

MCP Manager only accepts a federated identity whose email your IdP marks as verified. Confirm the user’s email is verified in your IdP. This guard is intentional and protects against accounts being claimed on your domain by someone who does not control the address.

The user signs in but sees no gateways

A just-in-time account has no team membership, and gateway access in MCP Manager comes from teams. Add the user to a team — automatically through SCIM group-to-team mapping or manually on the team — so they gain access. See SCIM provisioning and Teams.

The IdP dashboard tile does not sign users in

The tile requires the OIDC application to allow IdP-initiated launch (in Okta, Either Okta or App), to display its icon to users, and to have its Initiate login URI set to the tenant-scoped sign-in URL we provide (https://gateway.mcpmanager.ai/auth/login?tenant=your-workspace-tenant). Confirm those settings, that the tenant value matches the one MCP Manager gave you, and that the user is assigned to the OIDC application.

Further reading

Supported identity providers

The searchable list of IdPs MCP Manager works with for SSO and SCIM.

SCIM provisioning

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

Teams

How team membership grants users access to gateways.

Roles

How roles and capabilities govern what users can do.

External sources

Okta OIDC app setup

Okta’s guide to creating an OIDC Web Application integration.