Skip to main content
Single sign-on and SCIM provisioning are enterprise features, configured per organization. Your MCPJam contact provides the setup links for your organization. Complete and test single sign-on before configuring provisioning.
MCPJam supports SAML 2.0 or OpenID Connect (OIDC) single sign-on and SCIM 2.0 user provisioning with Okta. Your Okta admin does the setup once, in a guided flow. Your directory then controls membership: assigning someone to MCPJam in Okta gives them access, and unassigning them takes it away. Choose one SSO protocol for your organization. SCIM provisioning is configured separately and works with either protocol.
Until MCPJam is available in the Okta App Catalog, use a custom app integration as described below. Your organization can configure SSO and provisioning before the catalog listing is published.

​
Before you start

  • An MCPJam organization on a plan that includes SSO, and a setup link for it. Your MCPJam contact provides one; each link is specific to your organization.
  • Okta admin access, enough to add an app integration and configure provisioning.
  • Your email domain verified on your MCPJam organization. We do this for you when you’re onboarded — it’s what lets us route your users to Okta and manage their accounts.

​
Part 1 — Single sign-on with SAML

1

Open the setup link and choose Okta SAML

The setup portal shows two values for your organization: an ACS URL and an SP Entity ID. Keep this tab open — you’ll come back to it in step 4.
2

Add MCPJam in Okta

In the Okta Admin Console, go to Applications → Create App Integration, choose SAML 2.0, and name the app MCPJam. If Okta offers a choice of creation experiences, choose Classic experience.In the app’s SAML setup, paste the values from step 1:
3

Check the attribute mappings

Configure these attribute statements in the SAML app:Use the email address as the Name ID, with the email address format. Role assignment is configured separately; adding a groups attribute alone does not grant administrative access.The id attribute must contain the immutable Okta user ID. Configure it in the app’s attribute statements, using the expression exactly as shown without ${...} around it. An empty id causes sign-in to fail even when the email and name attributes are correct.
4

Send Okta's metadata back to MCPJam

On the app’s Sign On tab, copy the Metadata URL. Paste it into the MCPJam setup portal from step 1 and finish. Test a sign-in after the connection becomes active.
5

Assign users and test

Assign users or groups to the MCPJam app in Okta. Assigned users can now sign in — from the Okta dashboard, or by entering their work email on the MCPJam sign-in page, which redirects them to Okta.Accounts are created automatically on first sign-in, with membership in your MCPJam organization. Nobody needs to be invited by hand.

​
Alternative — Single sign-on with OIDC

Use this instead of the SAML setup when your organization chooses OIDC.
  1. Open your SSO setup link, select Okta OIDC, and copy the Redirect URI.
  2. In Okta, create an OIDC – OpenID Connect → Web Application integration. Paste the full URI into Sign-in redirect URIs and assign the users who should have access.
  3. Copy the app’s Client ID and Client secret from its General tab into the matching fields in the MCPJam setup portal. Keep PKCE enabled.
  4. Set Discovery Endpoint to your Okta tenant’s discovery URL, shaped like https://your-company.okta.com/.well-known/openid-configuration.
  5. Save the setup and test sign-in from MCPJam using an assigned user’s work email. The integration uses the openid, profile, and email scopes for the user’s identifier, name, and email address.
The OIDC client secret belongs in the SSO setup portal. It is separate from the SCIM bearer token used for provisioning. If email-domain discovery selects a different organization, use an organization sign-in link supplied by your MCPJam contact: https://app.mcpjam.com/login?organization_id=YOUR_WORKOS_ORGANIZATION_ID. This link selects that organization’s configured SSO connection, including when you already have a session in another organization. Users must still authenticate with the identity provider and meet the organization’s access requirements.

​
MCPJam integration fields

If you are installing a supplied MCPJam integration that asks for these fields, use the values below. Custom apps configured with the steps above take the full URLs instead. These identifiers are case-sensitive. Copy them exactly from your own organization’s setup portal. The directory identifier is not the bearer token. For a supplied MCPJam SAML integration, configure the immutable user identifier on the app’s Sign On tab. Expand Attributes (Optional) under the SAML settings and add oktaUserId with the value user.getInternalProperty("id"). Your MCPJam contact must map this connection’s IdP ID to oktaUserId before you test sign-in. This app-level statement avoids the OIN template’s different expression syntax. Custom SAML apps use the id statement in Part 1 instead.

​
Part 2 — Provisioning (SCIM)

SCIM keeps MCPJam membership in sync with your directory. Deprovisioning deactivates the user’s organization membership and revokes their WorkOS sessions.
1

Open the provisioning setup link

Choose Okta. The portal shows a SCIM endpoint and a bearer token.
2

Enable provisioning in Okta

Use the MCPJam provisioning integration if one was supplied. Otherwise, add SCIM 2.0 Test App (OAuth Bearer Token) from Okta’s App Catalog and give it a recognizable label such as MCPJam Provisioning.Open Provisioning → Configure API Integration and enable API integration. Enter the full endpoint in SCIM 2.0 Base URL and the bearer token in OAuth Bearer Token (or API Token). Paste the token itself; Okta adds the Bearer authorization prefix.Click Test API Credentials and save after it succeeds. Under Provisioning → To App, enable:
  • Create Users
  • Update User Attributes
  • Deactivate Users
3

Assign users or groups

Okta now manages the lifecycle:
  • assigning someone provisions their MCPJam account and organization membership;
  • profile changes sync automatically;
  • unassigning or deactivating someone deactivates their MCPJam membership and revokes their WorkOS sessions.
When SSO and provisioning use separate Okta apps, assign each user to both. Test provisioning, sign-in, deactivation, and reactivation with a pilot user before assigning the rest of your team.

​
Roles

MCPJam organizations separate owner, admin, and member access. Admins manage members and organization settings; members work in the product without administrative access. Owners additionally control ownership and billing. Users signing in through Okta are members by default. Your MCPJam contact can configure group-to-role assignments for your directory. Confirm those mappings and test both an admin and a standard member before relying on them.

​
Troubleshooting

The Single Sign-On URL or Audience URI in Okta doesn’t match the values from the MCPJam setup portal. Re-copy both from the portal — they are unique to your organization.
Their email domain may not be verified on your MCPJam organization, so we can’t tell which organization they belong to. Contact us and we’ll verify it.
Re-check the SCIM endpoint and bearer token — tokens are specific to one directory connection. If you removed and re-created the connection, the old token stops working. In particular, do not put the directory identifier from the endpoint into the API Token field. Re-copy the actual bearer token and run Test API Credentials again.
Okta suspension does not send a provisioning deactivation. Unassign the user from the provisioning app or deactivate the Okta user to trigger SCIM deprovisioning.
Deactivated members are retained for audit purposes, without access — their sessions are revoked and they cannot sign in.

​
Support

Email support@mcpjam.com or your MCPJam contact.