Some Magento stores aren’t meant for the public. Employee shops sell discounted merchandise or equipment to staff. B2B portals show contract prices that competitors shouldn’t see. Members-only and wholesale stores sell to approved buyers only. In every case the requirement is the same: nobody sees anything until they have signed in, and signing in should use the account they already have.

Magento Open Source doesn’t have a built-in setting for this, and the usual workarounds have gaps.

Why the common workarounds fall short

  • Hiding prices or “add to cart” for guests still exposes the catalog, the product structure and often the prices through search pages, structured data or the GraphQL API.
  • HTTP basic authentication in the web server keeps everyone out, including search engines you might still want on the landing page. It also means a shared password and a second login prompt, and it often breaks payment provider callbacks.
  • Custom redirect observers are written quickly and then forgotten. They tend to loop on the login page, block password resets, or cache a redirect for everyone in full-page cache.

The other half of the problem is the accounts. A private storefront is only as private as its customer list. If accounts are created by hand and never removed, people who left the company or the customer contract can still sign in.

Require sign-in for the whole storefront

IdPlug Admin SSO adds a website-level setting for this: Stores > Configuration > Services > IdPlug > Storefront > Require Sign-in for the Whole Storefront. It is off by default and can be enabled per website, so a public brand site and a private B2B site can share one Magento installation.

When it is on, guests are sent to sign in, with deliberate exceptions:

  • Pages Open to Guests lists the routes and pages that stay public, for example contact, cms/page/view or an /imprint page.
  • Login, password reset and IdPlug’s own sign-in routes are always open, so nobody gets stuck in a redirect loop. With SCIM installed, the provisioning endpoint stays reachable too.
  • POST requests without cookies, such as payment webhooks, pass through.
  • AJAX requests from guests receive HTTP 401 instead of an HTML redirect, which front-end code can handle cleanly.

Saving the setting cleans Magento’s full-page cache, so cached public pages don’t leak through. If you run Varnish or a CDN in front of Magento, purge it yourself after turning the setting on.

One important boundary: REST, GraphQL and the admin are not affected. If your catalog data or prices must stay private, restrict API access separately, for example at the web server or the CDN.

Sign in with the identity they already have

A private storefront with yet another password is a support burden. Customers forget it, share it, and call you when they are locked out. With single sign-on, people use their company account:

  • Employee stores connect to the company’s own Microsoft Entra ID or Okta. Follow our Entra ID setup guide.
  • B2B portals can connect each customer company to its own identity provider, because IdPlug Admin SSO supports several providers per website, with a priority and a default. One company might use Entra ID with OpenID Connect and another a SAML provider; the SAML vs OpenID Connect comparison explains the trade-offs.
  • Groups decide what people see. Map groups from the identity provider to Magento customer groups, and the customer group drives prices and tax classes as usual, and catalog permissions on Adobe Commerce.

Native login can stay available as a fallback for buyers whose company has no identity provider.

Keep the customer list in sync

For employee stores especially, combine the private storefront with SCIM provisioning. Entra ID or Okta then creates the Magento customer before the first visit, with the right customer group. When an employee leaves, it deactivates them; the order history stays, but they can no longer sign in, and with Sign out deactivated customers any open session ends too.

That is the full picture of a private storefront: provisioning decides who has an account, single sign-on proves who is signing in, and the storefront setting makes sure nobody else sees the shop.

Headless storefronts work too

If the private store is a PWA or another headless front end, such as PWA Studio, Alokai or a custom app, IdPlug Admin SSO also handles headless sign-in. The front end sends the shopper to IdPlug’s sign-in URL with a registered return URL, receives a one-time code, and exchanges it for a standard Magento customer token over REST (POST /V1/idplug/customer-token) or GraphQL (idplugCustomerToken). The token never appears in a URL. Because the storefront setting doesn’t cover APIs, a headless private store should enforce sign-in in the front end itself.

Getting started

IdPlug Admin SSO starts at $249 for the first year on Magento Open Source and includes the private storefront, multiple identity providers, headless sign-in and administrator single sign-on. Compare it with the other modules on the IdPlug overview. If you’re planning a new B2B or employee store, our Magento development team can build it end to end.