Columns2026/09/14

From Multipass to custom IdP connection: Key considerations for SSO migration between your company's membership base and Shopify

In this article, you will learn:

→ Why Multipass will become unusable. What "the underlying infrastructure will end" means, rather than "abolition."
→ What it will be replaced with. What is the difference between passing tokens and delegating authentication?
→ Whether existing membership databases can be used as-is, and how to determine this.
→ What options are available if your membership database is not an IdP.
→ How the login experience for existing customers will change.
→ What to do first, in what order, and by when.

"We allow customers to log in on our own website and then seamlessly access Shopify. What will happen to this setup?" This has been the most frequent question we've received recently.

The mechanism for transferring login states from an external site to Shopify has historically been handled by Multipass. This feature is exclusively for "legacy customer accounts." And legacy customer accounts were deprecated on February 26, 2026. While **stores currently using it can continue to do so for the time being**, if the underlying infrastructure is removed, the features built upon it will also cease to function.

This article will clarify what will change, when, what will replace it, and what decisions your company needs to make and when. We will focus on authentication and SSO (a mechanism that allows users to navigate multiple sites after a single login).

What's happening now?

In short, **there has been no announcement that "Multipass will be abolished."** What has been announced is the deprecation of the underlying legacy customer accounts.

Shopify deprecated legacy customer accounts on February 26, 2026. They cannot be used for new stores, and existing stores that have not used them previously cannot access them. Stores that are already using them will continue to function for the time being, but feature improvements and technical support will cease. The end date is expected to be announced within 2026, and as of September 2026, it remains undisclosed.

Multipass can only be used with legacy customer accounts. The official documentation clearly states, "Multipass login is only available with legacy Customer accounts." There's no need to wait for the end date of Multipass itself; the relevant date is tied to legacy customer accounts.

Figure ①: What has been announced, what has not, and what businesses need to do. The deadline is tied to legacy customer accounts, not Multipass.

How will the mechanism change?

The alternative is the "Custom IdP Connection" for new customer accounts. This feature, which connects an IdP (Identity Provider, an authentication server handling logins) to Shopify using OIDC (OpenID Connect), became available on December 11, 2024.

The biggest difference is that **the control and the direction of the arrow are reversed**. With Multipass, the external site verifies the password, bundles customer information into JSON, creates an encrypted and signed token, and sends it to Shopify. Shopify trusts that token and logs the customer in (creating an account if one doesn't exist). Only the external site would prompt the customer.

With a custom IdP connection, the customer first comes to Shopify. Shopify then requests the external IdP to "authenticate this person," and the IdP completes the authentication and returns an ID token. What is passed is not a "claim of authentication" but a "request for authentication," with the IdP responsible for providing the answer.

Shopify's feature comparison page also contrasts legacy customer accounts with "Multipass which doesn't support SSO" and new customer accounts with "any OAuth2.0 + OIDC-compliant identity provider." It is positioned as a way to share login states across sites, apps, storefronts, and checkout.

Figure ②: Differences between Multipass and custom IdP connection. The actors are the same, but the direction of the arrows is reversed.

Figure ③: Multipass login flow (conventional). The external site verifies the password. Shopify does not prompt the customer for anything.

Figure ④: Custom IdP connection login flow. The IdP provides the login screen. Shopify does not receive passwords.

How will the prerequisites change?

The requirement for Shopify Plus remains unchanged. What changes are the requirements for the external site.

Item	Multipass	Custom IdP Connection (OIDC)
Applicable Plan	Shopify Plus	Shopify Plus
Applicable Account	Legacy Customer Account	New Customer Account
Required for External Site	Ability to create signed tokens	Being an OIDC-compliant IdP
Customer Matching	Email address	`email` and `sub`
Customer Information Transfer	Carried in token	Claim import

Being "OIDC-compliant" is a more specific requirement than one might think. The full list of requirements is on the requirements page, and I've put them at the end of the FAQ in a format that can be sent directly to your membership database developer. There are two points that are worth noting for non-engineers.

One is that **support for the logout standard (`RP-Initiated Logout 1.0`) is mandatory**. Custom-built membership databases sometimes implement the login side but not the logout side. The other is that **three endpoints must respond within 1 second**. Exceeding this will cause login failures. This can be a practical hurdle for older membership databases.

If your membership database is not an IdP

In many cases, an external site's membership database only "has its own login screen and password verification" and cannot act as an IdP. There are two options: either rebuild the membership database itself to be an IdP, or place an authentication-only service (IDaaS, a cloud service that handles only the login part) in front of the membership database, and **replace only the entry point while keeping the member data within your company**. The latter option has a shorter development time but incurs monthly fees proportional to the number of members.

Specific product candidates are listed in the FAQ under "Which IdPs can be used?"

`email` and `sub` for matching

Shopify identifies customers by the `email` and `sub` fields in the ID token. `sub` (subject) is an immutable ID issued by the IdP for that person. The idea is to have a number that indicates "the same person" independently of the email address, as email addresses can change.

Two things can be said from this. First, **if email addresses are duplicated within the membership database, it will cause a roadblock there**. If there are two members with the same email address, Shopify cannot decide which customer it is. Deduplicating tens of thousands of records can be a months-long task in itself, so **estimate this as the longest part of your migration plan upfront.**

Secondly, if you rebuild the IdP, the `sub` will also change. Members will encounter an error saying "The sign-in method you used doesn't match this account." While recovery is possible, there is no official way to relink accounts in bulk by manually opening each customer in the admin panel and pressing `Unlink` (customer information and orders are not deleted). **Design with the assumption that you will not rebuild it.**

Customer information can be passed via claims. However, it may be overwritten each time.

Customer attributes can also be included in the ID token. These are called claims, and Shopify writes the received values to customer fields. The official mapping is as follows:

Claim	Shopify Customer Field
`given_name` / `family_name`	First Name / Last Name
`phone_number`	Phone number (E.164 format)
`address`	Address
`urn:shopify:customer:addresses`	Addresses (multiple)
`urn:shopify:customer:tags`	Tags

However, whether it can be passed depends on the product. Shopify's official Amazon Cognito integration guide explicitly states that **it does not support the standard `address` scope**. To pass addresses, a custom claim `urn:shopify:customer:addresses` needs to be constructed, and it's not guaranteed that "addresses will automatically be imported because claim import exists."

Another point to note is that data import is not limited to the first time.

Item	Behavior
Synchronization itself	Can be disabled all at once with a toggle in the admin panel
Synchronization timing	When enabled, it syncs each time a customer logs in
Overwrite rule	Either "Do not overwrite existing customer data (only update empty fields)" or "Overwrite existing customer data"
Email address	Only synced when creating an account, as it's the matching key

The settings are located under Settings > Customer accounts > Authentication > Manage > Identity provider > Manage providers. If you leave "Overwrite" enabled, **even if you fix customer information in the Shopify admin panel, it will revert to the IdP's value upon the next login.**

Of particular concern are **tags. If overwritten, all tags for that customer will be replaced as a whole, not one by one.** If you're using tags for segmenting deliveries or differentiating valuable customers, any tags not sent from the IdP will disappear. Names and addresses will also be replaced as a whole for each field (e.g., first and last name for names, one set of address information for addresses). Decide which — the IdP or Shopify — should be considered the source of truth before connecting.

Figure ⑤: Admin screen "Customer Data Synchronization" settings.

How will the customer login experience change?

First, the login screen will be that of the IdP. Both the design and wording will be from the IdP's screen. From the customer's perspective, it will be an experience where "clicking login takes them to a different screen," and **if the appearance changes, they will disengage there.** The extent to which logos, color schemes, and domains can be unified varies by product, so this is a factor to check during the IdP selection phase.

Next, passwords. There are two options. One is to ask everyone to reset their passwords at the time of the switch. This is reliable, but customers who don't respond to the mass email will be unable to log in and will disengage.

Another method is to **query and verify with the old membership database only for the first login, and if successful, transfer that password to the new IdP**. Customers can log in with their usual ID and password, and from the second time onwards, only the new IdP will be used. Amazon Cognito offers hooks for embedding custom processing during initial login, and other IdPs may have similar mechanisms. However, **you will have to create the process for querying and verifying with the old database yourself.** Check this before assuming that "mass password resets are unavoidable."

A common misconception here concerns password policies. It's tempting to raise the policy to "minimum 8 characters, special character required" during the migration, but **the new policy will not be applied during the transfer.** Amazon Cognito's official documentation explicitly states that for migrations, policies are not enforced, and passwords that do not meet the policy are accepted as-is. This means that raising the policy won't stop the transfer, but **existing customers will still be able to log in with weak passwords.** If you want to block them and force a reset, you'll need to implement that check yourself. When and to whom to ask for a reset is a decision separate from the migration.

Figure ⑥: Flow when migrating existing passwords. The migration proceeds as customers log in. Customers who do not log in are not migrated.

What we learned from actual implementation

**Connecting itself is not difficult.** Shopify provides a guide, and you can test it with `Test connection`. When people say "just connect the IdP," they are only referring to this part.

**The difficult part is after it's connected.** You'll need to decide, one by one, what the source of truth is, who owns which data, and how existing customers will re-authenticate. Here are points that we found, through verification with Amazon Cognito, need to be decided in advance to avoid backtracking. Many of these are not flaws in the product but rather **results of prioritizing security for an identity management platform**, and similar constraints exist for other IdPs. Please read this as a guide to check against your company's candidate products.

Stumbling blocks with screens and wording

**The wording on the login screen may not be changeable.** Cognito's new login screen defaults to English, and adding `?lang=ja` to the URL will make it Japanese. However, **the wording itself cannot be edited.** Furthermore, to use this screen and Japanese localization, a higher-tier plan is required; lower-tier plans only offer the older screen. AWS has not publicly stated the reason for this restriction, but we believe it is a security measure to prevent malicious actors from creating fake warning messages if the authentication screen's wording could be freely altered.

**Error messages may appear in English.** In our testing, while login failures appeared in Japanese, **only input validation for new registrations remained in English** (it didn't change even with `?lang=ja`). If a member makes an input error and receives an English message, that's a poor experience to present as-is. **If you want to convey it in Japanese, you'll need to validate and block the input yourself** before accepting the registration. This increases the amount of custom development required.

Stumbling blocks with data

**IdP connection is not a mechanism for migrating data.** This is the most common misunderstanding. Shopify does not receive a list of members. **The moment a customer logs in for the first time, they are matched one by one using the `email` in the ID token; if not found, an account is created on the spot.** This means customers who don't log in will never appear in Shopify. If you want to have customers pre-populated in Shopify before the switch, you'll need to **design a process to import them via the Admin API, separate from the IdP.** Authentication wiring and data migration are distinct tasks.

**Claim import is not foolproof.** Claims included in the ID token are imported into customer fields, but it is the IdP's job to include them. Especially in the case of Cognito, Shopify's official guide explicitly states that **it does not support the standard `address` scope**. To pass addresses, a custom claim `urn:shopify:customer:addresses` needs to be constructed, and furthermore, that process must complete within 1 second every time a user logs in.

**Email addresses are only synchronized when an account is created.** This is because they serve as the matching key (Shopify official). This means that **even if a customer changes their email address on the IdP side, it will not be reflected in Shopify's customer data.** You will need to provide both an email address change screen and a mechanism to flow that change to Shopify yourself. Please note that this is handled differently from names and addresses.

Stumbling blocks with the migration process

**Required fields on the IdP side may not be changeable later.** In Cognito, you cannot add new required fields after registration; changing them requires recreating the entire user pool. Recreating the user pool also changes the `sub` (subject identifier), making it essentially a one-time decision. Before building your production environment, decide what information you need to make mandatory during registration.

**If you allow login with a member ID, you need to design a different entry point.** "Login with member number" is not uncommon, but **the only way to identify a member in Shopify is by their email address** (internally, `sub` is also used, but this is an ID assigned by the IdP and not entered by the member). You need to design your IdP so that whether a member ID or an email address is entered, it leads to the same person.

**You need to block the path for existing customers to "register a new account."** Login screens usually have a link for new registrations. If a customer who has not yet migrated registers there, a separate account will be created from their old membership, and they will unknowingly be unable to see their purchase history or points. **This is where the most inquiries about "cannot log in" or "history disappeared" arise.** Implement a process to check for existing members and block new registrations at the same time as the switch.

**The speed of migration is determined by customer login frequency.** In a password transfer system, the query to the old membership database only occurs during the initial login. Conversely, **customers who only purchase once a year will not be migrated for a year.** When the old system can be shut down cannot be decided internally and will be determined by observing the migration rate. Furthermore, immediately after the switch, initial logins will concentrate, so **you must first check the processing limit of the old system.**

Estimated progress

The most important thing is to **align the account switch and the IdP's operation to the same moment**. Multipass cannot be used with new customer accounts. Therefore, if you complete the migration first, **SSO from external sites will be broken during the period until the IdP is connected.** Customers will log in on your company's website but will be prompted to log in again on the Shopify side.

Here's how you can structure the sequence. Shopify's upgrade procedure has 9 steps. **Steps 1 through 8 are for preparation and testing, and the online store and checkout remain connected to legacy customer accounts.** IdP connection provides a `Test connection` option, allowing you to connect and test during this period. The actual switch happens only once in step 9, at which point `Multipass` stops and the IdP takes over.

There's essentially one decision to make: **can your current membership database be used as an IdP as-is?** If it can, you only need to add an OIDC endpoint. If not, the process of rebuilding your membership database into an IdP or placing an IDaaS in front of it comes first. This is a question difficult for your company to answer internally, so you'll need to ask the party who built your membership database. What to ask is summarized at the end of the FAQ.

Figure ⑦: Aligning IdP operation with the moment of switch. Up to step ③, legacy customer accounts remain active. The switch happens only once at ④.

Note that you **can revert to legacy customer accounts within 30 days** after the migration. However, the official documentation only states "You can revert within 30 days," without specifying what is preserved upon reverting. Don't proceed with the assumption that reverting is always an option; instead, plan a process that avoids the need to revert.

How to migrate the customer account page itself is covered in another article. Please refer to it as well.

Frequently Asked Questions

What happens to existing customers?

Customers will be matched by email address, so if the email addresses are the same, they will be treated as the same customer. Conversely, if email addresses are duplicated in the membership database or differ from those registered in Shopify, they will be treated as different individuals. We recommend reconciling the email addresses in both systems before the switch.

How will the login experience change?

The login screen will be that of the IdP. Depending on how passwords are migrated, customers may be able to log in with their existing ID and password. If not migrated, they will be asked to reset their password at the time of the switch.

By when should I take action?

The end date for legacy customer accounts has not yet been announced as of September 2026. It is expected to be announced within 2026. However, since feature improvements and technical support have ceased with deprecation, there is no reason to wait for the end date announcement. The more members you have, the more time will be required for resolving duplicate email addresses and testing.

Should I wait for a new API to replace Multipass?

As of September 2026, there is no announced plan for a replacement API. Since it's impossible to plan for something that hasn't been announced, it's recommended to proceed with considerations based on a custom IdP connection.

What if I don't have Shopify Plus?

Custom IdP connection is exclusive to Shopify Plus. For plans other than Plus, SSO with external sites is not possible. You will need to use the standard login for new customer accounts (one-time code) and find creative ways to display the content of the customer account page. This point is covered in more detail in the customer account page migration article.

Should I migrate to new customer accounts and connect the IdP simultaneously?

If you are using Multipass, **you should do it simultaneously.** Since Multipass cannot be used with new customer accounts, if you only migrate first, SSO from external sites will be broken during the period until the IdP is connected.

Fortunately, Shopify's upgrade procedure involves 8 stages of preparation and testing, during which the online store and checkout remain connected to legacy customer accounts. IdP connection also includes a `Test connection` feature. **Connect and test during the preparation phase, then switch everything at once during the 9th upgrade stage** to ensure uninterrupted SSO.

Which IdPs can be used?

Shopify officially provides connection procedures for the following four (as of September 2026). These offer a faster startup due to the existing guides.

Product	Provider
Amazon Cognito	Amazon Web Services
Auth0	Okta
Okta	Okta
Microsoft Entra ID	Microsoft (Entra External ID for consumers)

Other products or self-built IdPs can also be connected if they meet the conditions on the requirements page. As a **reference**, here are examples of products that have received OpenID Foundation certification as OpenID Providers:

Product	Positioning
Keycloak	Open-source. Self-hosted and managed.
Authlete	Japanese product. Used as a component to turn an existing membership database into an IdP.
IBM Security Verify	Authentication platform for large-scale deployments.
Ping Identity	Also for large-scale deployments. Integrated ForgeRock in 2023.

**Certification is granted for specific versions and does not mean the latest version is certified.** And **this certification proves OIDC compliance, not compliance with Shopify's requirements.** Logout standards and 1-second response times need to be verified separately, and without official Shopify guides, the verification effort will fall on your side. If you have candidates, first compare them against the requirements page.

What should I ask the party who built our membership database?

I've formatted it so you can send it directly. It's a list for answering the third question (Can the membership database become an IdP?):

Does it support OpenID Connect **Authorization Code Flow**? (Implicit and Hybrid flows cannot be connected)
Does it support **`RP-Initiated Logout 1.0`**? (Back-Channel / Front-Channel cannot be connected)
Can it publish a **Discovery** endpoint (URL that returns configuration details)?
Do the Token, Discovery, and UserInfo endpoints respond **within 1 second**?
Can it issue **refresh tokens**?
Can it include **`sub`**, **`email`**, and **`email_verified`** in the ID token?
Can you guarantee that member email addresses are **always unique and not duplicated**?
Can names, phone numbers, addresses, and tags be included as **claims**? (Phone numbers in E.164 format, prefectures and countries as ISO codes)

Items that receive a "no" answer will serve as a basis for deciding whether to rebuild the membership database or delegate authentication to a different service.

If our in-house membership database can directly become an IdP, how much easier will it be?

**The authentication side will be significantly easier.** Since passwords are not migrated, there's no need for transfer implementation or mass password resets. The entire structure where customers migrate one by one upon their first login disappears, and **everyone can log in from day one after the switch.** There's also no need to decide when to shut down the old membership database. Since the login screen and mandatory registration fields are your own, the restrictions peculiar to managed IdPs mentioned in this article do not apply.

**On the other hand, the data side will not be any easier.** Shopify does not receive a list of members, so if you want to pre-populate customers before the switch, the process of importing them via the Admin API still remains. Email address duplication is a fundamental issue with the matching key itself, so deduplication also remains. Claim design, deciding whether names and addresses should be sourced from the IdP or Shopify, the mechanism for reflecting email address changes in Shopify, and the process to block existing customers from going through new registration are all still necessary.

The difficulty lies less in "connecting authentication" and more in " **determining data ownership**," which is a more accurate understanding of the situation.

How much does an IdP cost?

Many products use usage-based billing based on MAU (Monthly Active Users - the number of unique users who log in that month). Keep in mind that the number of members directly translates to monthly costs. The approximate monthly cost for 50,000 MAU, based on public pricing as of September 2026, is as follows (excluding free tiers, discounts, and exchange rates).

Product	Billing Concept	Estimated Cost for 50k MAU/month
Amazon Cognito (Essentials)	$0.015 / MAU	$750
Microsoft Entra External ID	Free up to 50,000 MAU, then pay-as-you-go	$0 (Additional costs for storage in Japan)
Auth0 (B2C Essentials)	Monthly fee based on MAU tiers	$3,500

Even with the same number of members, there can be a several-fold difference depending on the product. Please check each company's pricing page for the latest figures.

Summary

Multipass is not being deprecated; rather, the underlying legacy customer accounts will be retired. The date to watch is for legacy customer accounts.
The initiative shifts from Shopify to the IdP. The biggest deciding factor is whether your company's membership base can function as an OIDC IdP.
Decisions that cannot be changed later (required fields, login identifiers, matching keys) come before the work itself. Make these decisions before starting. Email address normalization is the process that should be tackled first.

If you need assistance with the migration process or determining whether your company's membership base meets the requirements, please contact us.

References

The information in this article is as of September 2026. Shopify specifications and service fees may change. Please check Shopify's official documentation and each service's official page for the latest information.