Single Sign-On for PeakCommerce Sites
Single sign-on (SSO) lets people reach PeakCommerce without maintaining a separate password here — they authenticate once with an identity provider they already use, and PeakCommerce trusts that result. The benefit is fewer passwords to manage, centralized control of access and MFA in your own identity system, and faster onboarding and offboarding of staff and customers.
PeakCommerce has two independent SSO paths because two different audiences sign in to two different surfaces. Both are arranged with your PeakCommerce implementation team — neither is self-service in the admin UI.
Staff / enterprise SSO (Admins & CSRs)
Your internal Admins and CSRs sign in on the staff plane (the admin portal hosts). PeakCommerce connects to your corporate identity provider over OpenID Connect (OIDC) — for example Okta, Microsoft Entra ID, or any compliant OIDC provider — so staff use their existing corporate credentials and your IdP enforces password and MFA policy.
The login surface decides the population: staff hosts pin Auth0 to your staff connection, so users go straight to your IdP rather than a connection picker.
PeakCommerce reads identity claims only (
sub,email,name) from the token. Roles and permissions are never taken from the token — they are resolved from the PeakCommerce database when the session is established, so your IdP cannot escalate a user's access.New staff can be provisioned just-in-time on first login into a least-privilege "pending access" profile, then promoted by an Admin. See What your web team needs for SSO for the exact handshake values.
End-customer portal SSO
Separately, your end customers can be signed into the customer portal automatically from inside your own product — they click a link in your app (where your app is the identity provider) and land in PeakCommerce already authenticated. This is a silent, app-initiated handoff suited to "My Account" style links.
The handoff is a signed token (signed-JWT / OIDC) your app mints and PeakCommerce verifies (signature, audience, expiry, and single-use replay protection) before establishing the portal session.
Identity is joined by email; an existing portal user is matched, otherwise one is provisioned automatically.
An SSO'd customer lands on the Customer Default profile unless a profile claim in the token maps them to another in-tenant, customer-role profile. A token can never grant a staff-level or out-of-tenant profile.
The token can also carry the customer's external account reference, linking the portal session to their subscriptions and invoices.
This path is configured by the implementation team (secrets, audience, and issuer are set per environment); it is not exposed as a tenant-facing setting.
Related
Last updated
Was this helpful?