Download the PHP package dmlab/module-customer-sso without Composer

DmLab_CustomerSso

Provider-agnostic single sign-on for the Magento 2 storefront (OIDC).

This is the storefront-login capability core: it logs shoppers in over OIDC but never references a concrete IdP. Install a provider plugin (e.g. customer-sso-okta) to bind it to an identity provider.

Features

• JIT customer creation — an unknown identity provisions a new customer_entity on first sign-in.
• Account linking by IdP sub first, then by email under policy.
• Group mapping — an IdP claim maps to a Magento customer group.
• Coexists with password login — the native email/password form stays available (configurable).

Installation

Usually installed via a provider plugin, which pulls this core (which pulls sso-core):

Direct install of the core alone:

Register the module callback URL in your IdP: https://<store-host>/customersso/sso/callback. It must exactly match the storefront URL used at runtime.

Configuration

Admin → Stores → Configuration → DMLab → Customer SSO → General (config path dmlab_customer_sso/general/*). Settings are store-scoped, so SSO can be enabled and tuned per store view.

The "Sign in with SSO" button appears on the customer login page when the module is enabled and a provider is selected; it uses the active preset's branding. Setting Keep Password Login to No hides the native form once SSO is live. As a break-glass, the form stays visible on an unconfigured or broken install (no active provider), so a mis-set toggle can never lock shoppers out.

Account linking

An SSO identity is matched to a customer in this order:

1. By IdP sub — the stable subject stored in dmlab_customer_sso_subject on first link. A customer is EAV/API-backed, so the link lives in its own table rather than a column on the entity.
2. By email, governed by auto_link_policy:
   • auto — a matching email signs straight into the existing customer.
   • require_verification (default) — email linking is refused until the email is proven, preventing account takeover via an unverified IdP email.
3. JIT create — no match → a new customer_entity is provisioned from the identity, and the sub is stored for stable re-login.

require_verification is the safe default; switch to auto only when the IdP guarantees verified emails.

Group → customer-group mapping

group_customer_group_map takes one rule per line as idp_group=customer_group_id, where customer_group_id is a Magento customer_group id. Blank lines and # comments are ignored; on duplicate groups the later line wins.

With no rules configured this is inert: customer groups are never touched, so a store using SSO only for login keeps its manually assigned groups. Once a map exists, groups are resolved on JIT create and refreshed on every login, so IdP group changes take effect at next sign-in. An identity whose groups match no rule reverts to the store's default customer group (GroupManagementInterface::getDefaultGroup) — customers always hold a valid group. A rule pointing at a non-existent group id is skipped, leaving the current group unchanged.

How it works

1. Shopper clicks "Sign in with SSO" → customersso/sso/start builds the OIDC auth URL (state + nonce + PKCE) via sso-core and the active preset, persists that state in the customer session, then redirects to the IdP.
2. IdP redirects back to customersso/sso/callback, which validates state, exchanges the code, and normalizes claims into an Identity via sso-core. IdP error responses return to the login page with a message.
3. The customer is matched (sub → email-under-policy → JIT create) and the sub link is stored.
4. The customer group is resolved from IdP groups and the storefront customer session is established.

Requirements

• Magento 2.4.x
• PHP 8.3 – 8.5

Part of the DMLab identity suite

License

https://dmlab.work.