Shopify Customer Accounts Now Support Your Own Identity Provider — But Only If It Returns a Refresh Token

By Milan Dhameliya · · 9 min read

Shopify Plus stores can replace the default customer accounts sign-in with their own OpenID Connect identity provider — Okta, Auth0, Entra ID, or a homegrown one. It's a real, generally available feature, and it's also easy to configure in a way that quietly cuts every customer's session from Shopify's usual 90 days down to whatever your provider's access token lasts, sometimes one hour. Here's what the setup docs don't warn you about, and who should actually build this.

Shopify lets stores on the Plus plan replace the default sign-in on customer accounts with their own identity provider — Okta, Auth0, Microsoft Entra ID, or anything else that speaks OpenID Connect. It's a real, generally available feature you turn on from Settings > Customer accounts, not a beta and not an app you install. It's also easy to configure in a way that quietly cuts every customer's session from Shopify's usual 90 days down to however long your provider's access token happens to live — which, for a default Auth0 setup, is one hour.

Shopify's own identity provider docs and shopify.dev reference walk through the connection steps well enough. What they don't do is tell you which of those steps are the ones that break in production, because the people who wrote them haven't had to field the support ticket where a customer got logged out mid-checkout for no visible reason. That's the part worth twenty minutes before you commit engineering time to this.

Why merchants reach for this instead of the default sign-in

Native Shopify customer accounts — passwordless, email plus a six-digit code — are the right call for almost every store, and if that description fits yours, you can stop reading here; there's no reason to take on an OIDC integration for its own sake. Connecting your own identity provider earns its complexity in narrower cases: a Plus merchant consolidating login across a storefront, a loyalty app, and a separate membership or community platform under one credential; an enterprise buyer who requires SSO through their own Okta or Entra ID tenant before they'll create an account at all; or, increasingly, a B2B store that has no other option left.

That last case is the one growing fastest. Shopify's own Multipass documentation confirms Multipass only works with legacy customer accounts and recommends migrating away from it. B2B functionality runs exclusively on new customer accounts, and legacy accounts never supported B2B at all — so a merchant who built single sign-on on Multipass specifically to give wholesale buyers a seamless login now has to replace it with something, and the OIDC identity provider connection is that something. If you're mid-migration off legacy accounts for other reasons, we cover the rest of that process in our legacy accounts rebuild guide; this post picks up specifically where that one leaves off, at the SSO replacement question.

The plan wall

This is Shopify Plus only, full stop — there's no workaround, no app that unlocks it on Advanced or lower, and no partial version. If you're not on Plus, the honest answer to "should I connect an identity provider" is that the question doesn't apply to you yet; native passwordless accounts are also what you're stuck with, and they're a perfectly reasonable default in the meantime.

What Shopify actually requires from your provider

Shopify's requirements page is thorough but easy to skim past. Hand this checklist to whoever administers your identity provider before you start, because a provider that fails any one of these items will connect in testing and then fail in ways that are hard to diagnose later:

The session-length trap: why 90 days can quietly become one hour

This is the gap nobody writing about this feature covers, and it's the one that generates support tickets. Shopify's native customer accounts stay signed in for up to 90 days. When you connect your own identity provider, that session length depends on your provider issuing a refresh token alongside the access token. Without one, the customer's session ends when the access token expires — commonly one hour — even though nothing on the Shopify side changed and the customer never explicitly signed out.

The reason this catches teams off guard is that refresh tokens aren't automatic on every provider. Auth0, specifically, does not return a refresh token by default; you have to explicitly request the offline_access scope in your application's configuration for Auth0 to issue one. A provider that connects cleanly, passes every claim check, and works fine in a five-minute test session will still fail this — because a five-minute test doesn't cross the one-hour boundary where the difference becomes visible. Test this specifically: connect, sign in, wait past your provider's default access-token lifetime, and confirm the customer is still signed in before you activate the connection for real traffic. If you skip that one test, you find out about the gap from a customer abandoning a cart after being silently logged out mid-session, not from your own QA.

Passwordless is the default — and it isn't always what a B2B buyer wants

Shopify's native customer accounts are passwordless by design, and most identity providers default the same way when you first connect them. That's a mismatch for a real, reported case: a developer working with a B2B client on Shopify's own developer forum found their client's buyers struggling with Auth0's passwordless flow and specifically wanting traditional username-and-password sign-in instead — the login pattern wholesale buyers are already used to from other B2B software they use daily. Shopify's representative confirmed OpenID Connect support makes this possible but pointed to Auth0's own configuration docs rather than Shopify-specific guidance, because none exists yet. If your B2B buyers are the audience, don't assume the identity provider's default connection type is the right one to ship — check what authentication method your provider offers (Auth0 calls it a "Database" connection for username/password, as distinct from its passwordless connection) and configure it deliberately before launch.

One active provider at a time

You can register more than one identity provider against a Shopify store, but only one can be active for sign-in at any given moment. In practice this rules out running two brands or two customer segments through two different providers simultaneously on a single store — if that's your setup, either consolidate behind one provider that can federate both populations, or split into separate stores under Shopify's multi-store tooling. This isn't documented as a limitation so much as mentioned in passing, which is exactly the kind of detail that should shape your architecture decision before you build, not after.

What happens when a login stops matching

Shopify identifies returning customers by matching the email and sub claims from your provider's token against existing customer records — a first login with a new email creates a new customer, and a matching email links to an existing one automatically. When that link breaks, usually from a customer's account being reprovisioned on your identity provider's side with a new sub value, they hit the error "The sign-in method you used doesn't match this account" and can't get back in on their own. Until recently the fix required contacting Shopify Support directly. Shopify has since shipped a self-serve unlink option in the admin, from the customer's detail page, that clears the mismatched link without touching order history — worth knowing before you tell a locked-out customer to wait on a support ticket. Verify the request through your existing identity-verification process before unlinking anyone, since removing the wrong link hands account access to whoever asks next.

If you're also changing your customer accounts domain

One more sequencing detail that's easy to get backwards: if you're planning to change the domain your customer account pages run on — something we cover from the domain side in our customer login troubleshooting guide — update your identity provider's redirect and callback URLs first, then change the domain in Shopify. Doing it in the other order leaves your provider pointing at a URL that no longer resolves, and every customer is locked out simultaneously until someone notices and fixes the callback configuration.

Should you actually build this

Build it if you're on Plus and at least one of these is true: you're migrating B2B buyers off Multipass and need an SSO replacement, you're consolidating login across a storefront and a separate platform your customers already use daily, or an enterprise buyer requires SSO through their own identity provider as a condition of the account. For B2B specifically, the pricing and account-management surface tends to have its own rough edges worth auditing at the same time — see our B2B catalog and pricing integrity guide if you're setting this up alongside company accounts and tiered pricing.

Skip it if none of those apply. Native passwordless accounts are simpler, need no OIDC configuration to maintain, and don't carry the session-length or passwordless-mismatch risks above. Adding an identity provider for a single-brand DTC store with no enterprise buyers and no cross-platform login need is complexity with no corresponding benefit — it gives your team a standing integration to keep patched against provider-side changes, for a login experience that's harder to debug than the one Shopify already ships for free.

If you're weighing this for a Plus or B2B build and want a second pair of eyes on the provider config before you activate it in production, get in touch — the refresh-token test above is the one thing worth getting checked before real customers hit it.