Skip to main content
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. 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 the FAQ).

​
How your team signs in

End users never create or manage an MCP Manager password. They sign in one of two ways: by clicking the MCP Manager tile on your IdP dashboard (if you configure one — see Add an MCP Manager tile to your IdP dashboard), or by entering their work email at the login page, where MCP Manager recognizes the registered domain and routes them to your IdP to authenticate.

​
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.
  • 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) — 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 — access in MCP Manager comes from team membership. Until a user is placed on a team, they can sign in but will not see any gateways.
  • SCIM is the durable path to team access. Pair SSO with SCIM provisioning so group membership flows from your IdP into MCP Manager teams automatically.

​
What you provide

Connecting your IdP is a short exchange: you create one application in your IdP and send us the connection details; we register your enterprise connection and confirm when it is live.
  1. Configure your IdP for a new OpenID Connect connection (in Okta, an OIDC — Web Application app integration) and provide us with all of the following:
    1. Issuer URL (ends with /.well-known/openid-configuration)
    2. Client ID
    3. Client Secret (the secret value, not its ID)
    4. The email domain(s) that should sign in through your IdP (for example, all users with an email address @yourcompany.com)
  2. Allow the following sign-in redirect (callback) URLs in your IdP application — paste them verbatim; the redirect URI must match exactly for the connection to succeed:
    1. https://login.usercentrics-sandbox.eu/login/callback (for our test system)
    2. https://login.usercentrics.eu/login/callback (for production)
    MCP Manager is a Usercentrics product — enterprise sign-in is brokered through Usercentrics.
Copy the block below into a secure form of communication, fill it in, and send it to your MCP Manager contact:
SSO connection details
The Client Secret is a sensitive credential, and the choice of secure channel is yours. Some customers create a secure note in their password management system and share a time-limited access link just for this process. If a secret is ever exposed, rotate it in your IdP and send us the new value.
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.

​
Troubleshooting

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.
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.
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.
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.

​
Frequently asked questions

Okta: create an OIDC — Web Application app integration. The Client ID and Client Secret are on the application’s General tab under Client Credentials. The Issuer URL is your Okta org domain followed by the discovery path: https://yourcompany.okta.com/.well-known/openid-configuration.Microsoft Entra ID: register a new app following Microsoft’s quickstart. The Issuer URL is listed under the Endpoints button in your app’s overview page. Create a Client Secret under Certificates & secrets — and send us the secret Value, not the Secret ID.
That choice is yours. If your security policy permits sending credentials by email, you can do that. We recommend a one-time link instead — a self-destructing secret link from your password manager or a one-time-secret service — so the value cannot be read again after we retrieve it. If a secret is ever exposed in transit, rotate it in your IdP and send us the new value.
Create a new secret in your IdP and send the new value to us through a secure channel; we update your enterprise connection and confirm when it is in place. Sign-ins through your IdP fail from the moment the old secret expires until the new one is active, so if your IdP enforces secret expiry (Microsoft Entra ID does by default), plan the rotation with us ahead of the expiry date.
Yes — we can route your email domain to a standard Google sign-in without any of the setup on this page. The difference from enterprise SSO is control: with Google sign-in, authentication happens against the user’s Google account rather than your IdP, so it cannot be enforced or centrally managed by your IT team, and it does not pair with SCIM provisioning for automatic team membership. Connecting your IdP as an enterprise connection gives you both.
No. A social “Sign in with Microsoft” button authenticates personal Microsoft accounts and is not compatible with your organization’s Microsoft Entra ID. If your organization uses Entra ID, connect it as an enterprise connection following the steps on this page — that is what routes your users through your directory, with your policies enforced.
We request the default OpenID scopes: openid profile email. No custom scopes or extension claims are required.
SSO handles authentication (who the user is), not authorization (what they can do). Access to gateways comes from team membership, and permissions come from roles — both managed in MCP Manager, or driven automatically from your IdP groups via SCIM provisioning. Blocking or removing a user in your IdP does stop them from signing in to MCP Manager.
No — keep at least one administrator account outside SSO as a break-glass account. Because MCP Manager routes sign-in by email domain, any domain you do not register keeps the standard email-code login. If your IdP ever has an outage or a misconfiguration, an administrator account on an unregistered domain can still sign in and restore access; registering every domain removes this safety net.
Your role does not have the Manage SSO/SCIM mapping capability, which controls visibility and access to the SSO / SCIM settings page — without it, the page is hidden and navigating to it returns you to the People area. Ask a workspace administrator to grant the capability to your role from People. Only the settings page is gated; the end-user sign-in flow works for anyone on a registered domain.

​
Further reading

IdP dashboard tile

Let users launch MCP Manager with one click from your IdP dashboard.

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.

Microsoft Entra ID app registration

Microsoft’s quickstart for registering an application and creating a client secret.