Customer cannot sign in via custom OIDC after previously using Shop Pay

GraphQL Admin API Troubleshooting
1

Hi,

We are investigating an issue with Shopify Customer Accounts and a custom OIDC identity provider.

Our store currently supports login through a custom OIDC server. The OIDC server supports both:

  • Email-based login
  • LINE Login (Japanese SNS provider)

In both cases, our OIDC server ultimately issues an ID token with claims similar to:

  {
    "sub": "email:user@example.com",
    "email": "user@example.com",
    "email_verified": true
  }

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:

  1. Is there any way to inspect which login method or external identity is associated with a Shopify customer account?
  2. 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?
  3. Does Shopify match external OIDC users only by sub, or can it link by verified email as well?
  4. Can an existing Shop Pay / Shopify-login customer be linked to a custom OIDC identity provider account?

Any guidance would be greatly appreciated.

2

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!