Single sign-on answers one question: who is this person right now? It doesn’t answer the two questions that cause the most trouble in B2B portals and employee stores:

  • Should this person already have an account? A new sales rep needs to see their customer group’s prices on day one, not after a first login and a support ticket.
  • Should this person still have an account? When an employee leaves or a customer company ends its contract, their Magento account should stop working that day.

Just-in-time provisioning creates a Magento customer at the first SSO sign-in. Nothing happens when someone leaves. That is the gap SCIM closes.

What SCIM is

SCIM 2.0 is an open standard (RFC 7643 and RFC 7644). An identity provider uses it to manage accounts in another application over a small REST API. The application, here your Magento store, exposes /Users and /Groups endpoints. The identity provider calls them whenever something changes:

  • A user is assigned to the application: create.
  • Their name, email or department changes: update, often as a PATCH with only the changed values.
  • They are unassigned, disabled or deleted: deactivate.
  • Group membership changes: group update.

Microsoft Entra ID calls this automatic provisioning, and Okta calls it lifecycle management. Both speak SCIM 2.0.

Why Magento needs special care

A Magento customer isn’t a throwaway account. It holds orders, invoices, addresses, saved carts and sometimes credit terms. A provisioning integration that hard-deletes customers when a user is removed in Entra ID destroys business records. A non-idempotent one creates duplicate customers every time the provider retries a request, and identity providers retry often.

IdPlug SCIM Provisioning is built around those constraints:

  • Soft deactivation, never deletion. Deactivation and DELETE preserve the customer and their order history but block access. A deactivated identity can sign in neither natively nor through SSO. With Sign out deactivated customers, active sessions also end immediately.
  • Reactivation restores the same account. Re-assign the user in Entra ID and the existing customer comes back with its history.
  • Idempotent provisioning. Repeated creates, updates and PATCH requests don’t produce duplicate customers. An existing customer with the same email is never silently claimed; the provider gets a 409 uniqueness error instead.
  • Groups drive customer groups. Group membership changes recalculate the customer’s Magento customer group. They use the same group mapping as single sign-on, so a company’s buyers land in the right price tier however their account was created.

Setting it up with Microsoft Entra ID

  1. Install IdPlug SCIM Provisioning next to IdPlug Customer SSO, and configure the Entra ID provider as described in our Entra ID single sign-on guide.
  2. On the identity provider record (IdPlug > Identity Providers), set Provisioning mode to SCIM only or SCIM + JIT, then generate a token in the SCIM credential panel. The token is shown once and stored only as a hash, so copy it now. You can rotate or revoke it at any time.
  3. In Entra ID, open the enterprise application, then Provisioning, and set the mode to Automatic. Enter the Tenant URL, your store’s HTTPS base URL followed by /scim/v2 (https://store.example.com/scim/v2), and the token as the Secret Token. Click Test Connection.
  4. Check the attribute mappings. Keep at least userName, active, name.givenName, name.familyName, emails[type eq "work"].value and externalId, with the Entra object ID as externalId. If customers also sign in with SSO, map the OIDC subject to the same oid claim so both paths link to one customer.
  5. Assign a small pilot group, then use Provision on demand to test the whole lifecycle: create, update, deactivate and reactivate one user.
  6. Turn on group provisioning once users behave as expected, then widen the assignment.

Setting it up with Okta

In Okta, configure the application for SCIM 2.0 with header (bearer) authentication, using the same base URL and token. Test the connector, then enable Create Users, Update User Attributes and Deactivate Users. Enable Push Groups and Push Group Membership only after the user tests pass. Use Okta’s stable user IDs as externalId.

Running it in production

Provisioning runs unattended, so you need ways to see what it did and to stop it safely:

  • IdPlug > Provisioning Diagnostics checks the endpoint and the token, and previews how a SCIM user and its groups would map, before real data arrives.
  • IdPlug > Provisioning Logs records every create, update, deactivation, reactivation and membership change, with an error code when something is rejected.
  • SCIM Emergency Pause, under Stores > Configuration > Services > IdPlug > Provisioning, makes writes return 503 with a Retry-After header while reads continue. Use it during a data migration or an incident. Entra ID and Okta retry later instead of failing permanently. The pause doesn’t revoke the token or affect sign-in.
  • Requests are rate-limited per credential, and a provider that sends too much gets a standard 429 with a retry delay.

Who needs SCIM, and who doesn’t

You probably need it if:

  • your store serves employees or B2B customer companies whose users live in Entra ID or Okta;
  • access has to end the same day someone leaves, for compliance, pricing confidentiality or contract reasons;
  • accounts need to exist before the first login, with the right customer group.

You probably don’t if your customers are the general public who register themselves. Single sign-on with IdPlug Customer SSO, which is free, is enough there.

SCIM pairs naturally with a private storefront that requires sign-in: provisioning decides who has an account, and the storefront makes sure only those people see anything. IdPlug SCIM Provisioning starts at $299 for the first year on Magento Open Source; see the product page for both editions and the optional installation service.