はじめに
複数のブランドをECで展開していると、あるとき必ずこの相談が出てきます。「サイトごとに会員登録が別々なのは、さすがに不便では？」と。
私が関わったのは、1つのShopifyストアを共有しながら、見た目もURLも別々の3つのブランドサイト（いずれもヘッドレスなNext.js）を運営しているケースでした。バックエンドの会員データは実は共通なのに、サイトをまたぐたびにログインし直さないといけない。これはもったいないですよね。
この記事では、なぜ会員を共通化したかったのか、そしてサイト間で「1度のログインを引き継ぐ」シングルサインオン（SSO）をどう設計したのか、その全体像をお話しします。
なぜ会員を共通化したいのか
ブランド横断の顧客体験
同じ会社が運営する3つのブランドを、お客様は必ずしも「別々のお店」とは思っていません。片方で買った人がもう片方も覗いてみる、という行き来は日常的に起きます。
このとき、サイトを移った瞬間に「またログインしてください」と表示されると、体験がぶつっと途切れてしまいます。すでにログイン済みの人には、そのまま買い物を続けてほしい。ブランドは分かれていても、「同じ自分」として扱われる。この地続き感こそが、共通化したかった一番の理由です。
ポイントと会員価格の共通化
バックエンドが同じShopifyストアである以上、ポイント残高も会員ランクも本来は1つのものです。にもかかわらずサイトごとにログイン状態が分断されていると、「Aサイトで貯めたポイントがBサイトで見えない」ように感じられてしまう。
会員価格の出し分けも同じで、ログイン状態が引き継がれて初めて正しい価格が表示されます。会員としての価値を、どのブランドにいても同じように受け取れる。それを技術的に支えるのがSSOでした。
分断されたログインの不便さ
サイトを移るたびに再ログイン。ポイントや会員価格が引き継がれず、離脱の原因に
1度のログインで3サイトを自由に行き来。会員情報もそのまま引き継がれる
再ログインの手間は、たった数十秒でも購買意欲を削ぎます。特にスマートフォンでの入力は負担が大きく、「面倒だからいいや」と離脱される要因になっていました。
Cookieがドメインをまたげない問題
そもそもなぜログインが分断されるのか
「バックエンドが同じなら、ログイン状態も勝手に共有されるのでは？」と思われるかもしれません。ところが、そうはいかないんです。
Webのログイン状態は多くの場合Cookieで保持されますが、Cookieには発行したドメインでしか読めないという厳格なルールがあります。brand-a.example で発行したセッションCookieを、brand-b.example から読むことはできません。バックエンドが同じでも、フロントのドメインが違えば別世界。ここが分断の正体です。
共通ドメインで済ませられないのか
サブドメイン共有は万能ではない
すべてを同一の親ドメイン配下（例: a.example.com / b.example.com）にすれば、Cookieのドメイン共有で解決できる場合もあります。ただしブランドごとに独立したドメインを使いたい、という要件があると、この手は使えません。
今回はブランドごとに独立したドメインを持つ方針だったため、Cookie共有という近道は最初から選べませんでした。だからこそ、「ドメインをまたぐ瞬間に、ログイン状態を安全に手渡す」仕組みが必要になったわけです。
手渡しという発想
答えはシンプルでした。Cookieが共有できないなら、サイトを移動する一瞬に、ログイン済みであるという証明書を「持たせて」渡してしまえばいい。
送り出す側のサイトが署名付きの証明書（ハンドオフトークン）を発行し、それを受け取った側のサイトが検証してセッションを作る。この「手渡しリレー」がSSOの核になります。
SSOの全体フロー
ハンドオフからセッション確立まで
ユーザーはサイトAにログイン済み。セッションはサイトAのCookieに保持されている
サイトBへのリンクをクリック。リンクは専用コンポーネントがSSO付きに変換済み
サイトAが署名付き・短命・使い捨てのトークンを発行（create-handoff API）
トークンを付けてサイトBのコールバックURLへリダイレクト
サイトBがトークンの署名・有効期限・未使用を確認し、自サイトのセッションを作成
利用者から見れば、リンクを踏んだら気づかないうちにログイン済みで表示される、というだけの体験です。裏側でこのリレーが一瞬で走っています。
3つの構成要素
ハンドオフトークンを発行
コールバックで検証・セッション確立
署名シークレット / 有効サイトリスト / 各サイトのコールバックURL
送出側・受入側・共通設定の3つがそろって初めてSSOは成立します。どのサイトも送出側にも受入側にもなり得るため、全サイトが同じ仕組みを対称に備えているのがポイントです。
セキュリティの基本方針
トークンは「本人であること」の証明書です。だからこそ、偽造されない・古くならない・使い回されない、という3点を必ず担保します。この3つが崩れると、SSOはそのままなりすましの入口になってしまいます。
まとめ
複数ECサイト間のSSOは、「Cookieがドメインをまたげない」という制約を、署名付きトークンの手渡しで乗り越える設計でした。要点を振り返ると次のとおりです。
- 会員共通化の目的：ブランド横断の顧客体験と、ポイント・会員価格の一貫性
- 分断の正体：Cookieはドメインをまたげないため、ログイン状態は自動共有されない
- 解決策：移動の一瞬に署名付きハンドオフトークンを手渡すリレー
- 安全性：署名・短命・使い捨ての3点で改ざんと再利用を防ぐ
より詳しい仕組みは、それぞれの記事で掘り下げています。トークン自体の設計は「署名付きハンドオフトークンの仕組み」で、受け取った側がどう検証してセッションを作るのかは「SSOコールバックとセッション確立のフロー」で解説します。そして、対象サイトを増やしても破綻しない設定管理の考え方は「サイト追加に耐えるSSO設定管理」にまとめました。