Skip to main content
Talk to an expert
OAuth logo

OAuth integration for ecommerce identity and access

Secure OAuth login linked to commerce and trade accounts iWeb designs the OpenID Connect flows, account linking rules and permission mapping so customers authenticate securely through your identity provider without password management overhead or orphaned access. 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.

OAuthiWeb 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 OAuth integration gives you.

Customers use corporate credentials everywhere

Employees and B2B buyers sign in with their corporate identity across web storefronts, trade portals and mobile apps without separate passwords. Account linking is transparent.

Trade permissions flow automatically from corporate groups

When a buyer joins a cost centre or project team in the identity system, their commerce permissions update automatically. Approval limits and visibility rules follow without manual account editing.

Access revocation is immediate and complete

When a team member leaves or their role changes, access to the trade portal and customer accounts is revoked within minutes. No orphaned sessions or ghost accounts remain.

MFA and session policy are enforced uniformly

Identity provider policies for multi-factor authentication and session timeout apply to commerce login, checkout and trade account access consistently. Compliance requirements are met in one place.

Audit trails show who logged in and why permissions changed

Login events and permission changes are recorded by both identity provider and commerce. Audit trails support compliance reviews and troubleshooting without manual log inspection.

02 · When it's worth it

Where a OAuth integration earns its place.

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

Single sign-on across storefronts and trade portals using corporate credentials
Linking customer accounts on the commerce platform to identity provider user records
Publishing user groups and buying roles from the identity system to commerce permissions
Controlling MFA policy and session lifetime for trade and corporate accounts
Deprovisioning access when users leave or roles change in the identity system
Separating consumer and B2B login experiences with different identity sources
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.

Standard OAuth doesn't carry role or permission detail

OAuth 2.0 itself carries minimal claims; OpenID Connect adds ID tokens with standard claims like email and subject. Custom attributes like cost centre, buyer role or approval limit must be added as custom claims and mapped in the integration layer.

No automatic account linking between identity and commerce

The identity provider doesn't know about existing commerce customer records. Someone must define the linking rule (by email, by external ID, by manual curation) and handle edge cases where the identity user doesn't yet have a commerce account.

Permission sync requires explicit group-to-role mapping

Groups from the identity provider don't automatically become commerce permissions. A mapping table must be maintained and refreshed when corporate structure or role definitions change.

Deprovisioning may be slow or incomplete

When a user is deleted or suspended in the identity provider, commerce doesn't automatically revoke access to trade accounts or orders in flight. Token revocation and session termination must be triggered explicitly.

No standard way to handle consumer and B2B separation

Commerce platforms often treat all logins the same way. If you need consumers to authenticate locally and B2B buyers to use corporate SSO, custom logic is required to route login flows correctly.

04 · The real work

Account linking and deprovisioning timing separate well-intentioned SSO projects from ones that survive a corporate restructure without orphaning access or locking out the wrong users.

05 · Where it sits

Where this integration sits in your estate.

OAuth 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. OAuth integrates with any ecommerce core through the same contract.

System of record
Source / owner
OAuth
Centralized authentication and permission control for commerce and trade access
  • User identity and verification
  • Multi-factor authentication policy
  • Group and role definitions
  • Session and token lifetime
  • Credential rotation and key management
iWeb integration layer
Customer-facing commerce
Commerce platform
Adobe CommerceMagento Open SourceShopify PlusBigCommerceOther storefronts
  • Customer account records and linking
  • Trade account permissions and overrides
  • Login session state on the storefront
  • Approval workflows tied to permissions
  • Order visibility and purchase authority rules
Connected neighbours
Integration layer
ERP
May hold the master customer account record and credit limit; identity system adds login credentials and trade permissions.
Integration layer
PIM
Not directly involved; identity system controls who sees which product catalogue.
Integration layer
OMS / Order management
May apply approval rules based on permissions derived from identity provider groups; deprovisioning must revoke approval authority immediately.
Integration layer
CRM / Marketing
May consume user identity events and consent status from the identity provider for segmentation and campaign eligibility.
Integration layer
Payments
Not directly involved; identity system ensures correct user is authenticated before payment methods are exposed.
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)
  • Azure AD / Entra ID
  • Okta
  • Keycloak
  • Google Identity
  • Customer data platform
  • ERP (for customer account master)
  • Trade portal or customer self-service
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 OTHER SYSTEMS
↔BOTH WAYS
Authentication assertion and token flow: The identity provider issues OpenID Connect tokens after login
Commerce verifies the token and maps claims (user ID, email, groups) to a commerce customer record or trade account. Session and MFA policy travel with the token.
User and group provisioning: User and group records flow from the identity provider into commerce via SCIM or direct API calls
Role mapping is applied so corporate groups become commerce permission sets on trade accounts.
Account linking and customer identity: Customer accounts created on the commerce platform can be linked to identity provider user records by email or username
Changes to email or account status propagate both ways depending on the system of record.
Group and permission changes: Changes to user groups and roles in the identity provider are reflected in commerce permissions
Deprovisioning events revoke access to trade portals and customer accounts immediately.
MFA and session policy: Policies for multi-factor authentication requirement, session lifetime and token refresh are enforced by the identity provider and honoured by commerce during checkout and account access.
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
    Map token claims to commerce customer and trade account records

    iWeb defines how user ID, email and custom claims from the OpenID Connect token link to commerce customer accounts and corporate buying roles. Fallback logic handles users without a pre-existing account.

  2. 02
    Build and maintain the group-to-role mapping table

    iWeb designs the governance rules for translating identity provider groups (department, team, location) into commerce permissions (buyer, approver, account manager). The mapping is versioned and auditable.

  3. 03
    Handle account linking and customer identity conflicts

    iWeb resolves ambiguity when a user exists in both identity provider and commerce but the link is unclear. Rules define whether identity is system of record or whether commerce customer records are canonical.

  4. 04
    Build deprovisioning and session revocation workflows

    iWeb designs the path from user deletion or suspension in the identity provider through to commerce session termination and trade account lock. Timing and ordering matter for compliance and customer service.

  5. 05
    Monitor token refresh, MFA and session health

    iWeb sets up observability so token expiry, refresh failures, MFA opt-out and session timeout are visible before they break login. Exception queues alert teams to certificate rotation or credential drift.

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 keys
Source / ownerIdentity provider (Azure AD, Okta, Keycloak, etc.)
Maintained byIdentity and access team
NotesPublic keys for token signature verification are retrieved by commerce and cached; certificate rotation must be coordinated with commerce deployment.
DataUser directory and group membership
Source / ownerIdentity provider
Maintained byHR and identity team
NotesChanges are either pushed to commerce via SCIM / API or pulled periodically; the sync pattern determines how quickly deprovisioning takes effect.
DataGroup-to-role mapping table
Source / ownerCommerce configuration or integration middleware
Maintained byCommerce operations or integration team
NotesDefines which identity provider groups become which commerce permissions; changes must be tested before deployment to avoid locking users out.
DataCustomer account linking rules
Source / ownerCommerce or integration layer
Maintained byCommerce or integration operations
NotesRules determine whether an OpenID Connect user is linked to an existing commerce customer record by email, external ID or manual curation; conflicts must be resolved before bulk linking.
DataSession and MFA policy
Source / ownerIdentity provider
Maintained bySecurity and identity team
NotesPolicies are enforced by the identity provider during authentication; commerce honours the token lifespan and MFA requirement via the OpenID Connect flow.
DataTrade account permissions and approval limits
Source / ownerCommerce
Maintained byCommerce or account management team
NotesDerived from group-to-role mapping; may be refined or overridden at the account level for special cases like cost centre restrictions or approver escalation.
10 · Experienced integrator

Built this before

iWeb has integrated OAuth 2.0 and OpenID Connect authentication into ecommerce and trade portal estates multiple times. We understand how token flows, account linking, group mapping and deprovisioning sit alongside ERP customer records, OMS approval workflows and trade account governance.

Designed account linking strategies that handle email collision, pre-existing customer records and just-in-time provisioning without orphaning users.
Built and maintained group-to-role mapping tables that survive corporate restructures and accommodate both bulk sync and emergency overrides.
Configured deprovisioning workflows that revoke trade account access, terminate sessions and archive customer records atomically, not in stages.
Integrated identity provider events with ERP customer master and OMS approval logic so permission changes take effect immediately in purchasing workflows.
Managed certificate rotation, key refresh and identity provider downtime so commerce login is resilient without becoming a security weakness.
11 · Before launch

What we test before launch.

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

Token validation succeeds with identity provider public keys; test key rotation and fallback to cached keys.
Account linking by email or subject ID creates or reuses the correct commerce customer record on first login.
Group-to-role mapping translates identity provider groups into commerce permissions without silent overrides.
Deprovisioning an identity provider user revokes their commerce session and trade account access within 5 minutes.
MFA requirement from identity provider is enforced and sessions are terminated if MFA is disabled in the identity provider.
Session timeout and token refresh work correctly across storefronts; token expiry during checkout triggers re-auth, not order loss.
Certificate rotation is detected and new keys are fetched without manual intervention or deployment.
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 accounts after deprovisioning

A user is deleted in the identity provider but their commerce session or trade account remains active. They can still place orders or access customer data until the token naturally expires or commerce is manually cleaned.

Group-to-role mapping drift after org restructure

Corporate groups are renamed or reorganised but the mapping table in commerce is not updated. Users in the new group structure either lose permissions suddenly or retain access to resources they should not see.

Token expiry breaks checkout in flight

A customer is halfway through checkout when their OpenID Connect ID token expires. Commerce rejects the token, session is terminated and the order is lost. No retry path exists.

Account linking ambiguity creates duplicate records

A user with the same email exists in both identity provider and commerce customer records but they are not linked. The user signs in and creates a second commerce account, fragmenting order history and permissions.

MFA policy change silently breaks access

The identity provider enforces MFA suddenly but commerce doesn't support MFA challenges. Users cannot complete login, and fallback to manual password reset is not defined.

Certificate or key rotation breaks token verification

The identity provider rotates its signing key or certificate. Commerce is still validating tokens against the old key and rejects all login attempts. No alert surfaces the mismatch until users report broken login.

13 · Where it applies

Relevant services and sectors.

14 · Questions

Common questions about OAuth integrations.

What is the difference between OAuth 2.0 and OpenID Connect?

OAuth 2.0 is an authorization standard for delegated access to resources; it does not carry user identity. OpenID Connect adds an identity layer on top of OAuth 2.0, issuing ID tokens that carry user claims (email, subject, groups). For ecommerce and trade portal login, use OpenID Connect so you get user information; OAuth 2.0 alone is suitable for API authorization.

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

The integration can link by email address (if it is unique and trusted in both systems), by external user ID (if the identity provider exposes it and commerce stores it), or by manual curation for edge cases. The linking rule is configured once and applied during first login or as a batch operation; after that, the OpenID Connect subject claim identifies the user.

What happens if a user exists in the identity provider but not yet in commerce?

On first login, the integration can either create a new commerce customer record automatically (just-in-time provisioning) or reject the login and ask them to register. Just-in-time provisioning is faster for end users but requires rules about which claims become which customer fields.

How are corporate groups converted into commerce permissions?

A mapping table translates identity provider group names into commerce permission sets (e.g., 'Finance-Team' becomes 'Approver' role, 'HR-Procurement' becomes 'Buyer' role). The mapping is maintained by the integration team and applied during login or group sync. If the group changes in the identity provider, the mapping must be updated to reflect the new permission set.

What happens when a user is deprovisioned in the identity provider?

When a user is deleted or suspended, the identity provider stops issuing tokens for them. Commerce should revoke any existing sessions immediately and prevent future login attempts with stale tokens. Deprovisioning workflows must handle trade account locks, order visibility revocation and customer record archiving to avoid orphaned access.

Can we enforce multi-factor authentication from the identity provider?

Yes. If the identity provider requires MFA, the user completes the challenge during the OpenID Connect flow and receives a token only after successful MFA. Commerce honours the MFA requirement because the token itself is proof that MFA was passed. If commerce adds its own MFA on top, you have defense-in-depth but also higher friction.

What should we do if the identity provider is unreachable during checkout?

If token verification fails because the identity provider keys are unavailable, commerce can either reject the request (hard fail) or allow a short grace period using cached keys (soft fail). Hard fail is more secure but blocks legitimate users; soft fail is more resilient but carries the risk of accepting an expired or revoked token. The choice depends on your security posture and downtime tolerance.

How long should sessions last, and who decides?

The identity provider usually sets the ID token lifetime (e.g., 1 hour) and issues refresh tokens for longer-lived sessions (e.g., 24 hours). Commerce should honour the token expiry and require re-authentication or refresh when needed. If commerce has its own session layer, ensure the lifetime is shorter than or equal to the refresh token lifetime to avoid sessions that outlive the identity provider's authority.

How do we handle the case where a user has multiple email addresses?

If the identity provider recognizes multiple email addresses for the same user but commerce treats each email as a distinct account, you must pick a canonical email or subject ID for linking. If a user links different emails to the same commerce account, use the subject claim (which is unique per user in the identity provider) as the stable identifier.

What happens if we rotate the identity provider's signing certificate?

The identity provider issues new tokens signed with the new key. Commerce must fetch the new public key (via the identity provider's JWKS endpoint) and validate tokens against it. This should happen automatically if commerce is configured to refresh keys periodically, but if it does not, tokens will be rejected until commerce is updated manually.

Can we use different identity providers for consumers and B2B buyers?

Yes. Commerce can be configured with multiple OpenID Connect identity providers and route login requests to the appropriate one based on the path (e.g., /consumer/login uses a local provider, /trade/login uses corporate SSO). The account linking and group mapping logic must be specific to each identity source.

How do we audit who logged in and why permissions changed?

The identity provider logs all authentication requests and token issuance. Commerce logs login events and permission changes tied to the user's subject ID. Audit trails should include timestamp, user, login success/failure, token refresh, group changes and permission updates. Both systems' logs should be available for compliance reviews.

What if a trade account needs approval limits that don't match the user's group?

Group-to-role mapping sets the baseline permission set. Commerce can then apply account-level overrides (e.g., this user can approve up to GBP 50,000 even though their group usually can approve up to GBP 10,000). Overrides should be rare, documented and separate from the group mapping to avoid confusion.

How do we handle the transition from local passwords to SSO?

Customers with existing commerce accounts can be invited to link their identity provider credentials by email verification or admin curation. Dual authentication (local and SSO) can run in parallel during the transition, with decommissioning of local passwords set for a future date. Account linking must happen before the cutover to avoid orphaned records.

Next step

Have a OAuth 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 →