Introduction
If you run multiple brands as EC sites, one request comes up sooner or later: "Isn't it a hassle that members have to register separately on each site?"
The case I worked on involved three brand sites (all headless Next.js) that looked and lived at completely different URLs, yet shared a single Shopify store on the backend. The member data was actually common, but you had to log in again every time you crossed from one site to another. What a waste, right?
In this article I'll walk through why we wanted to unify membership, and how we designed single sign-on (SSO) so that one login carries over across sites.
Why Unify Membership
A Brand-Crossing Customer Experience
Customers don't necessarily see three brands run by the same company as "three different stores." Someone who bought on one brand naturally wanders over to peek at another. That kind of back-and-forth happens all the time.
When "please log in again" pops up the moment they switch sites, the experience gets cut off abruptly. People who are already logged in should just keep shopping. Even if the brands differ, they're treated as "the same me." That sense of continuity was the number one reason we wanted to unify.
Shared Points and Member Pricing
Since the backend is the same Shopify store, the points balance and membership rank are inherently a single thing. Yet when login state is fragmented per site, it feels like "the points I earned on Site A aren't visible on Site B."
Member pricing works the same way — the correct price only shows once login state carries over. The value of being a member should feel identical no matter which brand you're on. SSO is what supports that technically.
The Friction of Fragmented Login
Re-login on every site switch. Points and member pricing don't carry over, driving drop-off
One login lets you move freely across three sites, member data intact
The chore of re-logging in — even just a few dozen seconds — chips away at purchase intent. Typing on a smartphone is especially burdensome, and it was becoming a reason for people to give up and leave.
The Problem: Cookies Can't Cross Domains
Why Login Gets Fragmented
You might think, "If the backend is the same, shouldn't login state be shared automatically?" But it doesn't work that way.
Web login state is usually held in cookies, and cookies have a strict rule: they can only be read by the domain that issued them. A session cookie issued on brand-a.example cannot be read from brand-b.example. Even with a shared backend, a different frontend domain is a different world. That's the real source of the fragmentation.
Can't We Just Use a Common Domain?
Subdomain sharing isn't a cure-all
If everything sits under the same parent domain (e.g. a.example.com / b.example.com), cookie domain sharing can sometimes solve this. But when the requirement is to give each brand an independent domain, that trick is off the table.
Because our policy was to give each brand its own independent domain, cookie sharing was never an option. That's exactly why we needed a mechanism to "safely hand off login state at the instant of crossing domains."
The Idea of a Hand-Off
The answer was simple. If cookies can't be shared, then at the very moment of moving between sites, we make the browser carry a certificate proving "already logged in."
The sending site issues a signed certificate (a handoff token), and the receiving site verifies it and creates a session. This "hand-off relay" is the core of the SSO.
The Full SSO Flow
From Hand-Off to Session Establishment
The user is logged in on Site A; the session lives in Site A's cookie
They click a link to Site B, already converted to an SSO link by a dedicated component
Site A issues a signed, short-lived, single-use token (create-handoff API)
Redirect to Site B's callback URL with the token attached
Site B checks the token's signature, expiry, and unused status, then creates its own session
From the user's point of view, it's simply: click a link, and it's already displayed as logged in. Behind the scenes this relay runs in an instant.
Three Building Blocks
Issues the handoff token
Verifies at the callback and establishes a session
Signing secret / list of valid sites / each site's callback URL
SSO only works when the sender, the receiver, and the shared configuration all come together. Since any site can be both a sender and a receiver, the key point is that every site symmetrically carries the same mechanism.
Security Fundamentals
The token is a certificate that you are who you say you are. That's why we always guarantee three things: it can't be forged, it doesn't age, and it can't be reused. If any of these breaks down, SSO becomes an open door for impersonation.
Conclusion
SSO across multiple EC sites was a design that overcomes the "cookies can't cross domains" constraint by handing off a signed token. To recap:
- Goal of unifying membership: a brand-crossing experience and consistency of points and member pricing
- Root of the fragmentation: cookies can't cross domains, so login state isn't shared automatically
- The solution: a relay that hands off a signed handoff token at the instant of crossing
- Safety: signature, short life, and single-use prevent tampering and reuse
Each detail is explored in its own article. The token design is covered in "How Signed Handoff Tokens Work"; how the receiving side verifies it and creates a session is in "SSO Callback and Session Establishment Flow"; and the configuration approach that survives adding sites is in "SSO Configuration That Scales with New Sites".
How Signed Handoff Tokens Work
Explains the design of single-use tokens valid only at the moment of crossing.
SSO Callback and Session Establishment Flow
Explains how the receiving site verifies the token and creates a session.
SSO Configuration That Scales with New Sites
Explains a setup where adding or removing sites is configuration only.