We have received reports that some customers who previously signed in using Shop Pay / Shopify’s standard official login system are unable to sign in through our custom OIDC provider.
When they try either email login or LINE Login through our custom OIDC server, Shopify shows an error message similar to:
│ Please sign in another way.
│ The login method you used does not match this account.
On our side, we confirmed that:
The customer record exists in our database.
The email address is correct.
For LINE users, the line_id is either correctly linked or not relevant.
Our OIDC server returns the same email-based sub regardless of whether the user signs in via email or LINE.
What we cannot confirm from our side is how Shopify internally associates the existing customer account with Shop Pay / Shopify’s standard login identity.
Our question is:
If a customer has previously signed in using Shop Pay / Shopify’s standard login system, and later tries to sign in using a custom OIDC provider with the same email address but a new OIDC sub, will Shopify
reject the login with this type of “login method does not match this account” error?
Also:
Is there any way to inspect which login method or external identity is associated with a Shopify customer account?
Is there a recommended migration or linking process for customers who previously used Shop Pay / Shopify’s standard login and now need to sign in through a custom OIDC provider?
Does Shopify match external OIDC users only by sub, or can it link by verified email as well?
Can an existing Shop Pay / Shopify-login customer be linked to a custom OIDC identity provider account?
Hey @shota, good questions! I took a look into this with the info you shared. When a custom OIDC provider is connected, Shopify uses the email and sub claims from the ID token to resolve the customer. If a customer profile already exists for that verified email, the login resumes that existing account rather than rejecting it, and if no profile exists a new one is created on first successful sign-in. So a brand-new sub for an email that already exists shouldn’t block login on its own. See the customer sign-in experience docs and the IdP requirements (email as the unique identifier, verification required).
On inspecting the linked identity, the older docs say the sub isn’t surfaced anywhere, but that’s changing. There’s an identityProviderSubjects field on the Customer object in the Admin API that returns the providerName and subject for each linked identity. It’s still rolling out, so you’ll currently only find it in the unstable version and not in the stable releases yet. There’s no merge/link mutation for attaching an existing Shop Pay or standard-login customer to a new OIDC sub. Linkage is implicit via the verified email, not by sub, so you don’t manually bind a previous account to the provider.
Given all that, the “login method does not match this account” behavior you’re seeing isn’t the documented matching path, so it’s worth a closer look. One documented thing to rule out first is that login is blocked with an error if the email_verified claim isn’t true, though from what you’ve shared yours is set correctly. Beyond that, since your store has Shop Pay active, it’s worth confirming you’ve added the Sign in with Shop button to your external sign-in page per the identity provider connect guide, as a Shop-managed identity on those emails is one possible angle.
To dig into a specific case, can you share the exact full error text or a screenshot, and an x-request-id from a failed sign-in attempt? With those I can trace what’s happening on a real account and bring in the right team if needed - thanks!
The error shown to the customer was:
“ご使用のログイン方法がこのアカウントと一致しません。”
In English, this means roughly: “The login method you used does not match this account.”
On our IdP side, the flow appears to complete successfully:
The email verification code was issued and accepted for test@example.com
Our system resolved the existing user from the database for that email
Shopify then called our /token endpoint with grant_type=authorization_code
NOTICE: email was masked actual email starts with shota and ends with @gmail.com.
One thing we noticed is that our external sign-in page currently does not show a “Sign in with Shop” button. It only offers LINE login and email verification.
Also, when we switched the configuration back to Shopify’s original identity server, the same customer was able to log in successfully using both Shop Pay and email login.
Given your previous explanation that Shopify should be able to resume the existing customer when the verified email matches, could you please check the above x-request-id and confirm why Shopify still rejects the login with “The login method does not match this account”?
Hi @shota, appreciate you following up! Thanks for the request ID, that let me trace the exact failure, and I need to correct what I said earlier.
The callback is returning a 409 conflict, which surfaces as “the login method does not match this account.” I mentioned above that linkage happens implicitly by verified email and that a new sub for an existing email shouldn’t block login which was wrong. Linkage is keyed on the sub.
The first successful login through your OIDC provider permanently binds that customer to the exact (provider, sub) pair it presented. On later logins, the email is only used to find the customer record, it doesn’t rebind the subject. So when a customer who already has a stored subject for your provider comes back with a different sub, Shopify treats it as a conflicting identity and rejects it with the 409, even though the email matches.
That points to the affected accounts already having a stored subject from an earlier login, with the sub your IdP sends now differing from it. The usual cause is the same person arriving with different sub values depending on the path they took (for example an email-based subject on one login and a LINE-based subject on another). Reverting to Shopify’s own identity flow likely works because that path resolves against a separate Shop subject mapping and isn’t gated by your provider’s stored subject.
You can confirm this per account. Query Customer.identityProviderSubjects on the unstable Admin API version to see the providerName and subject currently bound to a failing customer, then compare that stored subject against what your IdP sends on the failing login.
The fix is on the IdP side. Your provider needs to emit one stable sub per customer across every login method, so email and LINE logins for the same person resolve to the same subject. There’s no merge or relink mutation to repoint an existing customer at a new subject, so once a customer is bound, the only reliable path forward is consistent subjects going in.
I hope this helps, and apologies for the incorrect info earlier!
Thank you for guiding us on how to inspect identityProviderSubjects.
We were able to confirm the cause on our side. The affected test customer had an old identityProviderSubjects.subject value that came from a previous internal test version of our custom OIDC implementation, where the LINE user ID was used as the subject.
That version was never released to production. Our current production implementation uses a stable email-based subject, e.g. email:{verified_email}, and does not use the LINE ID as the OIDC subject.
Using the Admin GraphQL API, we confirmed that the affected customer still had the old subject value:
identityProviderSubjects.providerName: StoreCRM LINE
identityProviderSubjects.subject: old LINE user ID
So this appears to be caused only by legacy test data created during our pre-release testing, not by the current production behavior.
We appreciate your help, especially the suggestion to check identityProviderSubjects. That allowed us to identify the mismatch and confirm that there is no production impact.
At this point, we consider this issue resolved on our side. If you think there is anything else we should verify or clean up, please let us know.