Single Sign-On Across Multiple EC Sites

Introduction

Run several brands as EC sites and one request always turns up sooner or later: "Isn't it inconvenient that people have to register separately on each site?"

The case here involved three brand sites that shared a single Shopify store on the back end (the system that holds the product and member data), while looking completely different and living at completely different URLs. All three front ends were built as headless Next.js sites. The member data was already shared, yet users had to log in again every time they moved from one site to another.

This article covers why we wanted to unify membership, and how we built single sign-on (SSO) so that one login carries across sites. Rather than the fine detail of how the code is written, it lays out which parts exist and how they connect.

Why We Wanted Shared Membership

Users Move Between Brands

Users don't necessarily see three brands run by the same company as three separate stores. Someone who bought from one comes over to browse the other. That kind of back-and-forth happens all the time.

When "please log in again" appears the moment they switch sites, the whole flow stops right there. Someone already logged in should simply be able to keep shopping. Treating them as the same member even though the brands differ — that was the main reason we wanted a shared login.

Keeping Points and Member Pricing Consistent

Since the back end is the same Shopify store, the points balance and the membership rank are already single pieces of data. But when login state is cut off per site, it looks to the user as though the points earned on Site A simply don't exist on Site B.

Member pricing works the same way: the correct price only appears once login state carries over. Whatever brand you're browsing, you're the same member buying on the same terms. SSO is what supports that underneath.

What Re-Logging-In Costs You

Put simply, the one thing that changed is whether you have to type your details again each time you cross to another site.

Logging in again only takes a few dozen seconds, but some people abandon a purchase inside those seconds. Typing an email address and password on a phone is especially heavy, and it was a real reason for people to leave.

Why Login State Isn't Shared Automatically

A Cookie Can Only Be Read by the Domain That Issued It

You might expect login state to be shared automatically when the back end is the same. It doesn't work that way.

Web login state is usually held in a cookie (a small note stored in the browser), and cookies come with a strict rule: only the domain that issued one can read it. A login cookie issued on brand-a.example cannot be read from brand-b.example. Same back end or not, different front-end domains mean login state is tracked separately. That's the direct cause of the split.

Sharing a Subdomain, and Where It Stops Working

Our plan gave each brand its own independent domain, so the cookie-sharing shortcut was off the table from the start. We did consider grouping the sites under subdomains via DNS settings (the system that maps domain names to where the site is actually served from), but brand independence won out.

Handing Over a Certificate at the Moment of the Move

The approach we took is simple. If cookies can't be shared, then at the instant of moving between sites, hand the browser a certificate saying "this person is already logged in."

The sending site issues a signed certificate — a handoff token — and the receiving site verifies it and creates its own session. That exchange is the core of the SSO. The idea is not to redo the login, but to carry over the result of an authentication that already happened.

The Overall Flow and the Parts Involved

From Handoff to an Established Session

In one line: issuing, handing over, and verifying the certificate all happen in the instant it takes to follow a link. All the user sees is that the page opened already logged in.

Sender, Receiver, and Shared Configuration

What the diagram shows is that SSO only works when all three are in place: a sender, a receiver, and the shared configuration they both read.

Any site can act as the sender, and any site can act as the receiver. So every site carries the same mechanism symmetrically. Because no site gets special treatment, adding another one later follows exactly the same steps.

Signed, Short-Lived, Single-Use

What the table shows is that each of the three measures answers a different kind of attack.

The token is a temporary permit proving who someone is, so it has to be impossible to forge, impossible to keep using, and impossible to reuse — all at once. Drop any one of those and the SSO becomes a way in for impersonation. Gaps in an authentication spec turn into incidents directly, so at each design step we had an AI agent list out "if this condition were missing, what would become possible?" and worked through the answers.

Summary

SSO across multiple EC sites was a design that works around one constraint — cookies can't cross domains — by handing over a signed token instead. To recap:

1. The goal of shared membership: movement between brands, plus consistent points and member pricing
2. Why it was split: cookies can't cross domains, so login state isn't shared automatically
3. How we solved it: hand over a signed handoff token at the instant of the move
4. How it stays safe: signed, short-lived, and single-use, blocking tampering and reuse

Each piece 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".