Choose a Shopify single sign-on route by confirming the store’s eligibility and account version, then tracing the customer’s identity from sign-in through checkout and sign-out. For a new integration, start with the documented identity-provider route. For an existing Multipass installation, record its specific access conditions before planning changes or acceptance tests.
A useful brief begins with the journey you want to connect. A customer might sign in to a separate membership application and then enter the store to buy a product. Write down which system establishes identity, which record belongs to the shopper and where the session needs to continue. Keep account access separate from the business decision about what that customer may purchase.
The primary documents here were checked on 24 October 2026. They describe Shopify’s authentication routes rather than a completed integration. Use the accompanying worksheet to turn those mechanisms into a project-specific acceptance record. Keep broader commercial and payment questions with the Shopify eligibility guide and Shopify in Zambia.
Which route applies to the store?
Connecting an external identity provider to Shopify customer accounts requires Shopify Plus. Shopify supports connecting that provider through OpenID Connect. Those statements come from its customer authentication overview. Begin the eligibility record with the actual store, its plan and the account configuration being assessed. Record who inspected those settings and when.
The identity provider authenticates the customer and returns an ID token to Shopify. Shopify uses the token’s email and sub claims to identify the customer and create or resume a session. The same overview describes that flow. Draw those steps in the handover so the implementer and business owner can distinguish an external login from the resulting Shopify session.
The connected provider must support the authorisation code flow. Additional token claims can populate Shopify customer data through claim import. Treat the mapping as its own review task: name each intended field, its source and the owner of corrections. Keep the stable subject identifier and email address visible as separate concepts in the technical design, even when the public account screen mainly displays an email.
For Multipass, read the detailed guide’s availability notice before copying an older integration example. Multipass is no longer available to new stores. Stores already using Multipass retain access after upgrading to new customer accounts. Its current implementation guide describes that limited existing-store path. The overview still uses broad legacy wording, so preserve the detailed guide’s conditions and have Shopify resolve any uncertainty about the specific store before configuration changes.
The Multipass requirements also specify Shopify Plus. Record an existing installation’s route and entitlement evidence rather than treating the presence of an old code module as sufficient. For a new project, Shopify’s detailed availability notice directs builders towards a third-party identity provider. Keep that distinction in the decision record so a new build does not inherit an inapplicable historical assumption.
| Proposed situation | Evidence to obtain | Route to investigate | Acceptance focus |
|---|---|---|---|
| New connected identity service | Actual plan, account version and provider capabilities | Documented identity-provider connection | Correct customer and usable destination session |
| Existing Multipass integration | Existing use and store-specific access conditions | Detailed Multipass requirements | Current redirect, redemption and session behaviour |
| Profile data import | Agreed source fields and mapping | Supported claim import | Intended field values and correction ownership |
| Headless storefront | Storefront, account and checkout boundaries | Applicable checkout authentication guidance | Same intended shopper across the journey |
| Sign-out requirement | Session boundaries and intended termination scope | Route-specific logout design | Actual access after the intended termination |
This original matrix is a planning aid. Fill it with the store’s evidence and the selected provider’s applicable instructions. Give an unresolved eligibility row an owner and a next action; keep the rest of the design work grounded in the route that can actually be evaluated.
What should the identity-flow test prove?
Use a hypothetical test arrangement with a separate membership application, a Shopify test store approved for the chosen route and two fictional customers. Customer A has an existing sample store record. Customer B is a different synthetic identity. The exercise below is proposed, with no claim that an integration has been executed or approved.
Prepare an expectation sheet before any sign-in attempt. For each customer, record the external identity, intended Shopify profile, destination and sample order that should be visible. Add the expected handling of a newly introduced identity and the person responsible for investigating an unexpected match. Keep raw credentials and tokens outside the review sheet; use private references to the authorised technical evidence.
Shopify’s Multipass guide requires validation of the email used to register on the external site. Multipass documentation. Add an identity-provenance case before the happy path: Customer B claims Customer A’s synthetic email without controlling that mailbox. The proposed registration and sign-in process must prevent that claim from establishing access to A’s Shopify profile or order. Then demonstrate the approved email-verification route using a mailbox controlled for the test. Record the verification outcome and matched profile without retaining raw credentials or tokens.
Run the happy path first. Start signed out, follow the selected external sign-in route and inspect the resulting customer account. Record which customer was reached and whether the intended task can be completed. For the checkout stage, use the applicable Shopify guidance for that storefront arrangement and check the identity actually present there. A page loading successfully is only one observation in this sequence.
Then repeat the journey with Customer B in a separate approved test session. Ask the reviewer to compare the visible profile and sample records against the expectation sheet. Include a corrected test email and an unmapped optional field where the selected route supports those cases. Record the actual outcome without changing the expected identity merely to make the exercise appear successful.
How should replay and sign-out be checked?
A Multipass token is valid for 15 minutes. Each Multipass token can be redeemed only once. These are documented constraints of the Multipass route, rather than general limits for every identity-provider integration. Where that route applies, define controlled expired-token and repeated-redemption cases in the isolated test plan. Keep the observed result and the relevant application response together.
Ending the external site’s session does not by itself end the Shopify session. The detailed Multipass guide describes a backchannel logout route for stores using new customer accounts. This is why the sign-out row needs an explicit scope: external application only, a particular connected session or the full intended customer journey. Have the implementer explain the selected mechanism before the reviewer tries it.
For each sign-out case, write the intended state of the membership application, store, checkout and account pages. Follow the approved test procedure and check subsequent access at each relevant surface. Record both the request result and the observable session result. An accepted request should be interpreted according to its documented response semantics rather than treated as sufficient proof of every intended access change.
If the selected existing-Multipass route uses new customer accounts and session-scoped backchannel logout, include these documented distinctions. Each independently terminable session needs a distinct sid. A documented sid is a non-empty printable-ASCII string. The logout token must repeat the sid associated with that session. An empty or non-printable-ASCII sid can still return 204 and log the customer out of every session. A logout token with no sid ends every Shopify session for that customer on the store. A 204 response confirms request acceptance, not that a matching customer session ended. These are properties of the documented Multipass logout route, not universal rules for every identity provider.
For an authorised isolated rehearsal, establish two synthetic sessions with distinct valid identifiers. End one using its matching identifier and inspect both sessions against the intended scope. Test rejection of empty and non-ASCII identifiers in the implementation before sending a session-scoped request. If the approved test also exercises those malformed requests at the endpoint, check for the documented all-session outcome instead of assuming an error response or successful single-session logout. Exercise an omitted identifier only for a deliberate whole-customer logout case. Keep request status and observed access as separate results.
Conclude the handover with the eligibility evidence, identity map, route-specific test results and unresolved exceptions. Recheck that record when the account version, plan or provider configuration changes. Keep a named owner for the integration and a clear route for customer identity corrections.
Discuss the surrounding application through web development and the storefront through online stores. To scope the identity flow and its acceptance evidence, get started with the actual store configuration and the journey your customers need.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.