Skip to main content
Talk to an expert
SSO logo

SSO integration for ecommerce identity and access

Unified login and permissions across commerce and trade systems. iWeb connects your identity provider to ecommerce, trade portals and branch systems so users log in once and permissions stay in step. Permission mapping, account linking, MFA policy and deprovisioning workflows are all built to your governance rules. Works with Adobe Commerce, Magento Open Source, Shopify Plus, BigCommerce and other storefronts.

Also searched as: SSO, single sign on, identity provider, SAML, OAuth, LDAP, customer accounts.

SSOiWeb integration layeryour storefront
Talk to an expertSee the estate map ↓
Works with - Adobe Commerce · Magento Open Source · Shopify Plus · BigCommerce · Other storefronts
On this pageGet a brief reviewed
01 · What you get

What a SSO integration gives you.

One login for all

Users log in once via SSO and access ecommerce, trade portals, branch systems and customer-service tools without re-entering credentials. Eliminates password fatigue and support friction.

Permissions travel with the role

When a person's role changes or they move to a new team, permissions update automatically across all systems. No manual access grants or orphaned accounts.

Clear access audit trail

Every login, permission change, and access cut is logged. Compliance teams can audit who accessed what, when, and under what authority.

Fast offboarding

When staff or suppliers leave, SSO deprovisioning cuts access across commerce, trade systems and branch terminals in minutes, not days.

Trade-account governance

Corporate accounts, buying limits, approval workflows and cost-centre controls are enforced at login time so procurement rules stay consistent across all channels.

02 · When it's worth it

Where a SSO integration earns its place.

If two or more of these are true, the integration usually pays for itself quickly.

Central login for customers, trade users and branch staff across ecommerce, trade portals and EPOS
Permission mapping so buying roles, cost centres and approval authority travel with the account
Account linking between identity provider, commerce customer records and trade-account systems
Automatic provisioning and deprovisioning so access cuts cleanly when staff or suppliers leave
MFA and session control for trade-account security and compliance
03 · The limits

Where off-the-shelf connectors fall short.

Vendor connectors are fine for simple cases. Here's where the real ones need more.

Generic role mapping

Standard SSO connectors often map identity-provider groups to simple commerce roles. They struggle with buying limits, cost-centre rules, approval authority and trade-specific permissions that sit between the identity layer and order workflow.

Account linking ambiguity

If a customer exists both as an online shopper and a trade account, the SSO flow may not know which record to link to, creating duplicate accounts or loss of purchase history.

Deprovisioning lag

Removing a user from the identity provider does not automatically revoke sessions or cut access in all downstream systems. Trade-portal access or dormant sessions may persist until manually cleared.

MFA and session policy gaps

Commerce platforms and identity providers may enforce different session lifetimes, MFA policies or token refresh rules, leading to unexpected logouts or security gaps during peak trading.

Trade-account and branch integration

SSO connectors often assume a single online storefront. They do not naturally support trade-portal access, branch staff accounts, corporate-account hierarchies or local permission overrides in physical locations.

04 · The real work

Permission mapping and account linking are where SSO integration often breaks down; off-the-shelf connectors assume a single role-per-user model and do not handle buying limits, cost-centre rules or trade-account hierarchies.

05 · Where it sits

Where this integration sits in your estate.

SSO holds the commercial record. The iWeb integration layer manages the rules, mappings, monitoring and exceptions. The commerce platform presents the customer-facing experience. The estate map helps agree ownership before anything is built.

Built for your platform, not a specific one. SSO integrates with any ecommerce core through the same contract.

System of record
Source / owner
SSO
Authentication and access-control layer for login, permissions and account governance
  • User identity and authentication credentials
  • Group and role membership
  • MFA policy and session lifecycle
  • Audit events and login records
iWeb integration layer
Customer-facing commerce
Commerce platform
Adobe CommerceMagento Open SourceShopify PlusBigCommerceOther storefronts
  • Commerce customer account record
  • Cart, orders and customer history
  • Storefront session and checkout experience
  • Commerce-side permission enforcement
Connected neighbours
Integration layer
ERP
Provides trade-account, cost-centre and customer records that inform buying limits and approval authority.
Integration layer
Trade portal or B2B platform
Receives SSO tokens and enforces trade-account access and procurement workflows.
Integration layer
Branch EPOS and POS systems
Cache SSO sessions locally or validate tokens for in-store staff access.
Integration layer
Customer-service and order-management systems
Use authenticated user identity to ensure support staff see only accounts they are allowed to handle.
Integration layer
Audit and compliance logging
Receives login, permission and deprovisioning events for SOX, GDPR and other compliance reporting.
Two-way sync where relevant
06 · Surrounding systems

Systems this integration usually sits next to.

Examples, not a closed list. iWeb is platform-agnostic on both sides: we wire this integration into whatever ecommerce platform and surrounding systems your estate already runs.

Ecommerce platforms (examples)
  • Adobe Commerce
  • Magento Open Source
  • Shopify Plus
  • BigCommerce
  • Other storefronts
Surrounding systems (examples)
  • Okta, Azure AD or other identity provider
  • ERP system for trade-account and cost-centre rules
  • Trade portal or B2B platform
  • EPOS and branch systems
  • Customer-service platform
  • Audit and compliance logging
Not sure?

Not sure if this works with your stack?

Tell us what you’re using and what needs to connect. We’ll give you a straight view on what’s possible, what might be awkward, and the safest way to approach it.

07 · Data flows

The data flows we wire.

Each flow has a direction and an owner. We agree both before a line of code is written.

→Into COMMERCE
←From COMMERCE
↔BOTH WAYS
Authentication assertions: Login credentials and identity assertions flow from the identity provider into the commerce platform
The storefront validates the session and creates or updates the customer record with the authenticated identity.
User provisioning: New users are created in the identity provider and synced to commerce and trade systems
When users leave or roles change, deprovisioning events cut access across all connected systems.
Group and role mapping: Group membership and role assignments from the identity provider are translated into commerce permissions, buying limits, approval workflows and trade-account access rules.
Account linking: Authenticated user identities are matched to existing commerce customer records or corporate accounts so online and offline activity stays linked to the right person and company.
Session and token events: Commerce systems emit session and token state events back to the identity provider for auditing, compliance and session lifecycle management.
08 · How we build it

How iWeb configures the integration around your business.

Same method on every integration. The decisions come before the code.

  1. 01
    Design the authentication flow

    iWeb defines whether your users log in via SAML, OAuth 2.0 or OpenID Connect; how sessions are held on the commerce platform; and what happens when a session expires or MFA fails.

  2. 02
    Map identity to commerce roles and permissions

    iWeb translates identity-provider groups into commerce roles, buying limits, cost-centre codes, approval authority and trade-account membership so permissions reflect real business rules.

  3. 03
    Link accounts across systems

    iWeb builds the logic to match an authenticated user to their commerce customer record, corporate account, trade profile or branch staff account so history and permissions stay coherent.

  4. 04
    Handle deprovisioning and session cut

    iWeb builds workflows so when a user is removed from the identity provider, all sessions are revoked, trade-portal access is cut and branch terminals reflect the change within minutes.

  5. 05
    Monitor and audit identity flows

    iWeb instruments the authentication and permission paths so security teams see login events, permission grants, group changes and access anomalies in real time.

09 · Ownership

Who owns what.

The single most important table in any integration. One system owns each field; everything else reads it.

Data
Source / owner
Maintained by
Notes
DataIdentity provider configuration and credentials
Source / ownerIdentity provider
Maintained bySecurity and identity team
NotesiWeb uses provider credentials to fetch user, group and role data on schedule or in real time; rotation and secret management are the security team's responsibility.
DataUser and group provisioning / deprovisioning
Source / ownerIdentity provider
Maintained byHR and identity team
NotesiWeb listens to provisioning events and applies them to commerce and trade systems; the identity provider is authoritative for who exists and what groups they belong to.
DataSSO protocol setup (SAML, OAuth 2.0, OpenID Connect)
Source / ownerCommerce platform and identity provider
Maintained byiWeb and security team
NotesiWeb configures the commerce platform to accept assertions from the identity provider; both systems must be kept in step during upgrades and certificate rotations.
DataGroup-to-role and group-to-permission mapping
Source / owneriWeb integration configuration
Maintained byiWeb and business stakeholders
NotesiWeb maintains the mapping logic that translates identity-provider groups into commerce permissions, buying limits, approval authority and trade-account rules; changes require joint testing.
DataCommerce customer record and account linking
Source / ownerCommerce platform
Maintained byCommerce team
NotesiWeb supplies the matching logic; the commerce platform holds the customer record; the identity provider holds the authenticated identity; linking logic must handle duplicates and conflicts.
DataSession and MFA policy
Source / ownerIdentity provider and commerce platform
Maintained bySecurity team
NotesBoth systems enforce session lifetime and MFA rules; they must be aligned to avoid unexpected logouts or security gaps; iWeb monitors for policy drift.
DataAccess audit and compliance events
Source / ownerIdentity provider, commerce platform and logging system
Maintained bySecurity and compliance team
NotesiWeb ensures login, permission change and deprovisioning events flow to a central audit log; retention and compliance reporting are the security team's responsibility.
10 · Experienced integrator

Built this before

iWeb has designed and supported SSO integration patterns across ecommerce, trade portals, branch systems and corporate directories. We understand how identity provider protocols (SAML, OAuth 2.0, OpenID Connect) fit into commerce estates and where permission mapping and account linking usually cause friction.

iWeb has integrated Okta, Azure AD, Ping Identity and other enterprise identity providers with Adobe Commerce, Shopify Plus and Other storefronts.
iWeb builds permission mapping so identity-provider groups translate to commerce roles, trade-account buying limits, cost-centre rules and approval workflows.
iWeb designs account linking logic to match authenticated users to existing commerce customers, corporate accounts and branch staff records.
iWeb handles deprovisioning workflows so access cuts cleanly across ecommerce, trade portals, EPOS terminals and customer-service systems when users leave.
iWeb instruments audit trails so identity changes, permission grants and login events are visible to security and compliance teams.
11 · Before launch

What we test before launch.

Every one of these is rehearsed before a customer ever sees the integration.

Verify account linking: test that existing online shoppers, trade users and staff all map to the correct commerce customer and corporate records.
Test permission translation: confirm that identity-provider groups translate correctly to commerce roles, buying limits, approval authority and trade-account access.
Check deprovisioning: remove a test user from the identity provider and verify sessions are revoked, trade-portal access is cut and branch terminals reflect the change within 5 minutes.
Validate MFA and session policy: confirm that MFA is enforced correctly, session timeouts match security policy, and token refresh works during long-running transactions.
Test fallback behaviour: simulate identity-provider downtime and verify that users with active sessions can continue, and that new logins fail gracefully with clear messaging.
Audit logging: confirm that login events, permission grants, group changes and deprovisioning actions all flow to the compliance logging system with correct timestamps and user context.
Performance under load: run a load test with 500+ concurrent logins during peak trading to ensure SSO latency does not slow checkout or branch transactions.
12 · Failure points

Common risks and where they bite.

We name these on day one. A risk written down is a risk you can plan around.

Orphaned or duplicate accounts

If SSO account linking fails, users may create new accounts instead of linking to existing records, splitting purchase history and loyalty across duplicate identities.

Permission drift after role changes

If group-to-permission mapping is not automated, users may keep stale permissions after a role change, allowing access they should not have or blocking access they need.

Session token expiry during checkout

If SSO session lifetime is too short or token refresh fails, users may be logged out mid-purchase, causing cart abandonment or lost orders.

Deprovisioning delay or silent failures

If identity-provider changes do not propagate quickly to commerce and branch systems, a departing staff member or supplier may retain access for hours or days after they should be cut off.

MFA or certificate expiry breaking login

If MFA policies drift or identity-provider certificates expire without rollover, users may be locked out entirely. Certificate and policy rotation must be monitored and tested regularly.

Trade-account permissions not enforced

If SSO maps to commerce roles but does not translate to trade-account buying limits, approval workflows or cost-centre codes, users may bypass procurement rules or approve transactions outside authority.

13 · Where it applies

Relevant services and sectors.

14 · Questions

Common questions about SSO integrations.

Should we use SAML, OAuth 2.0 or OpenID Connect?

SAML works best for employee and trade-staff access where users are already in a corporate directory. OAuth 2.0 and OpenID Connect work best where users log in with social or consumer identities. iWeb recommends SAML for trade and branch access, and OIDC or OAuth for consumer accounts that may also link to corporate identity.

How do we link a user's identity-provider identity to their commerce customer account?

iWeb builds a matching strategy based on email, username, customer ID or a persistent identifier from the identity provider. For new users, a new commerce customer is created at first login. For existing users, iWeb uses a pre-loaded mapping or a just-in-time linking flow.

What happens if a user exists in both the identity provider and as an online shopper but under a different email?

This is a common scenario for shoppers who later join the company or a trade account. iWeb builds resolution logic so the first authenticated login either links to the existing customer or prompts the user to confirm. Manual reconciliation may be needed for legacy data.

How do we translate identity-provider groups into commerce buying permissions?

iWeb maps identity-provider groups to commerce roles and then translates those roles into buying limits, approval authority, cost-centre codes and trade-account access. The mapping is maintained by iWeb and reviewed during business-process changes.

How quickly are permission changes reflected when a user changes role in the identity provider?

If the identity provider supports real-time events, permissions can update within seconds. If using scheduled sync, updates happen at the next scheduled pull, typically every 15 minutes to hourly. iWeb recommends real-time events for trade staff and approval workflows.

What happens when a user is removed from the identity provider?

iWeb triggers deprovisioning workflows that revoke active sessions, cut trade-portal access and update the commerce customer record to disabled status. Branch terminals and customer-service systems are notified so the user cannot initiate new transactions.

How do we handle MFA for trade users and branch staff?

iWeb configures MFA policy at the identity provider level and ensures the commerce platform respects it. For branch staff, iWeb can support MFA on first login of the day or per-transaction depending on security policy.

Do we need to re-enter SSO credentials on mobile apps or at branch terminals?

iWeb can configure SSO to work seamlessly on mobile apps via OpenID Connect, and on branch terminals via cached sessions or device-level authentication. The approach depends on security policy and whether users are always online.

How do we handle trade-account hierarchies where some staff should see only certain divisions or locations?

iWeb uses identity-provider groups and attributes (like division code or location code) to filter the commerce and trade systems' visibility. For example, a user in the 'Manchester Branch' group sees only Manchester stock and orders.

What if the identity provider goes down? Can users still access ecommerce?

iWeb designs fallback behaviour: if the identity provider is unreachable and the user has an active session, they can continue. New logins are blocked until the identity provider recovers. For critical trade systems, iWeb may recommend a secondary identity provider or local cache.

How do we audit and report on who logged in and what they accessed?

iWeb instruments login, permission grant and access events and logs them to a central audit system. Security teams can report on login frequency, failed attempts, permission changes and suspicious activity patterns.

How do we handle SSO during an ecommerce platform upgrade or replatform?

iWeb re-establishes SSO configuration on the new platform and tests account linking and permission mapping thoroughly before cutover. If the identity provider certificate or protocol changes, both systems must be reconfigured in step.

Can we use SSO for customer-facing ecommerce, or only for trade and staff access?

SSO works for both. For consumer ecommerce, users log in via a social provider (Google, Microsoft, Apple) mapped to their consumer identity. For trade and corporate accounts, users log in via your corporate identity provider. iWeb can support both flows on the same storefront.

How does SSO work if we have multiple commerce platforms (ecommerce, trade portal, marketplace)?

iWeb configures the identity provider as a central hub so users authenticate once and receive tokens valid across all platforms. Each platform independently validates the token, but the user experience is a single login.

Next step

Have a SSO integration brief?

Send the brief, or tell us what is breaking. You will get a written response from a senior expert: the integration boundary, the realistic shape, the risks worth naming, and what it takes to support after launch.
Talk to an expertOr browse all integrations →