> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 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, just-in-time provisioning, and troubleshooting plus FAQs on sharing credentials securely, secret rotation, break-glass accounts, and social sign-in versus enterprise SSO.

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](/enterprise/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.

<Info>
  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](https://app.mcpmanager.ai/settings/people/sso) or talk to your MCP Manager contact.
</Info>

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

```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','actorBkg':'#aed8ff','actorBorder':'#0b4880','actorTextColor':'#062b4c','signalColor':'#6a6b76','signalTextColor':'#12141d','noteBkgColor':'#fff8e4','noteBorderColor':'#ffa535','noteTextColor':'#12141d'}}}%%
sequenceDiagram
    participant U as 👤 User
    participant M as 🛡️ MCP Manager
    participant A as 🔌 Auth0 (MCP Manager)
    participant I as 🔌 Your IdP (Okta / Entra ID)
    U->>M: Enter work email at app.mcpmanager.ai/login
    M->>A: Recognize email domain, start OIDC flow
    A->>I: Federate to your enterprise connection
    I->>A: Authenticate user, return verified identity
    A->>M: Return ID token (email, name, subject)
    M->>U: Provision/sign in, land in the workspace
```

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](#frequently-asked-questions)).

### 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](/enterprise/idp-dashboard-tile)), or by entering their work email at [the login page](https://app.mcpmanager.ai/login), 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](/enterprise/scim) 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)
   <Note>
     MCP Manager is a Usercentrics product — enterprise sign-in is brokered through Usercentrics.
   </Note>

Copy the block below into a secure form of communication, fill it in, and send it to your MCP Manager contact:

```text SSO connection details theme={null}
Issuer URL:        <https://your-idp/.well-known/openid-configuration>
Client ID:         <client-id>
Client Secret:     <client-secret-value>
Email domain(s):   <yourcompany.com>
```

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

<Check>
  Once the connection is live, a user on a registered domain who enters their work email at [the login page](https://app.mcpmanager.ai/login) is routed to your IdP to authenticate.
</Check>

## Troubleshooting

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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](/enterprise/scim) and [Teams](/deployment/teams).
  </Accordion>
</AccordionGroup>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Where do I find these values in Okta or Microsoft Entra ID?">
    **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](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app). 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.
  </Accordion>

  <Accordion title="How do I securely share the Client ID and Client Secret with you?">
    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.
  </Accordion>

  <Accordion title="My client secret expired or was rotated — what should I do?">
    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.
  </Accordion>

  <Accordion title="Can we use “Sign in with Google” instead of connecting our IdP?">
    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](/enterprise/scim) for automatic team membership. Connecting your IdP as an enterprise connection gives you both.
  </Accordion>

  <Accordion title="Is “Sign in with Microsoft” the same as connecting Microsoft Entra ID?">
    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.
  </Accordion>

  <Accordion title="Which OpenID scopes do you request?">
    We request the default OpenID scopes: `openid profile email`. No custom scopes or extension claims are required.
  </Accordion>

  <Accordion title="Does SSO control what users can do in MCP Manager?">
    SSO handles **authentication** (who the user is), not **authorization** (what they can do). Access to gateways comes from [team membership](/deployment/teams), and permissions come from [roles](/deployment/rbac-and-roles/overview) — both managed in MCP Manager, or driven automatically from your IdP groups via [SCIM provisioning](/enterprise/scim). Blocking or removing a user in your IdP does stop them from signing in to MCP Manager.
  </Accordion>

  <Accordion title="Should we route every email domain through SSO?">
    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.
  </Accordion>

  <Accordion title="Why can't I see the SSO / SCIM settings page?">
    Your role does not have the **Manage SSO/SCIM mapping** capability, which controls visibility and access to the [SSO / SCIM settings page](https://app.mcpmanager.ai/settings/people/sso) — 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](https://app.mcpmanager.ai/settings/people). Only the settings page is gated; the end-user sign-in flow works for anyone on a registered domain.
  </Accordion>
</AccordionGroup>

## Further reading

<CardGroup cols={2}>
  <Card title="IdP dashboard tile" icon="grip" href="/enterprise/idp-dashboard-tile">
    Let users launch MCP Manager with one click from your IdP dashboard.
  </Card>

  <Card title="Supported identity providers" icon="address-book" href="/enterprise/supported-identity-providers">
    The searchable list of IdPs MCP Manager works with for SSO and SCIM.
  </Card>

  <Card title="SCIM provisioning" icon="arrows-rotate" href="/enterprise/scim">
    Automatically create users and sync IdP groups to MCP Manager teams.
  </Card>

  <Card title="Teams" icon="users" href="/deployment/teams">
    How team membership grants users access to gateways.
  </Card>

  <Card title="Roles" icon="user-shield" href="/deployment/rbac-and-roles/overview">
    How roles and capabilities govern what users can do.
  </Card>
</CardGroup>

## External sources

<CardGroup cols={2}>
  <Card title="Okta OIDC app setup" icon="okta" iconType="brands" href="https://help.okta.com/en-us/content/topics/apps/apps_app_integration_wizard_oidc.htm">
    Okta's guide to creating an OIDC Web Application integration.
  </Card>

  <Card title="Microsoft Entra ID app registration" icon="microsoft" iconType="brands" href="https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app">
    Microsoft's quickstart for registering an application and creating a client secret.
  </Card>
</CardGroup>