はじめに
サイト間シングルサインオン（SSO）を3サイトで動かし始めると、次に必ず来る話があります。「4つ目のブランドを立ち上げるとき、どれくらい手間がかかるの？」という質問です。
ここで、SSOのロジックにサイトの情報が直接書き込まれていると大変なことになります。新サイトを足すたびにあちこちのコードを直し、テストし直し……となると、拡張が億劫になってしまう。この記事では、対象サイトの追加・削除を「設定を変えるだけ」で完結させるために、何をコードから追い出し、どう構成を管理したのかをお話しします。
設定に何を持たせるか
SSOに必要な3つの情報
SSOを成立させるために、全サイトが共有・参照する情報は突き詰めると3つです。これらをコードではなく環境変数などの設定として外に出します。
このうち署名シークレットは全サイトで同じ値を共有し、有効サイトリストとコールバックURLは「どのサイトが仲間で、どこへ送ればいいか」を示す名簿の役割を果たします。ロジックはこの名簿を読むだけ、という形にするのが狙いです。
なぜコードに書かないのか
サイトのドメインやURLをコードに直書きすると、それは「コード変更」になってしまいます。コード変更はレビューもデプロイも必要で、ちょっとした追加でも大掛かりになりがちです。
一方、設定として持たせておけば、名簿に一行足すだけ。ロジックには一切手を触れずに済みます。「変わりやすいもの（サイトの顔ぶれ）」と「変わりにくいもの（SSOの仕組み）」を分離しておく、という設計の基本ですね。この線引きが、後の運用をぐっと楽にしてくれます。
サイト追加を設定だけで完結させる
追加時にやること
各サイトのコードを修正し、レビューとデプロイをやり直す。追加のたびに大仕事
有効サイトリストとコールバックURLを設定に追記し、共有シークレットを渡すだけ
新しいブランドサイトをSSOの仲間に加えるとき、やることは驚くほど少なくなります。有効サイトリストにそのサイトを追加し、コールバックURLを登録し、共有シークレットを配る。この3点で、新サイトは送出側にも受入側にもなれます。
対称な設計が効いてくる
既存サイトと同じ署名シークレットを新サイトの環境変数に設定
全サイトの設定に新サイトを許可対象として追記
新サイトの受け入れ口を名簿に登録
専用リンクコンポーネントが新サイトへのリンクもSSO付きに変換
すべてのサイトが同じSSOの仕組みを対称に備えているからこそ、新サイトも「設定を配れば仲間入り」できます。特別扱いのサイトが存在しない、という均質さが拡張性の源になっているわけです。
サイト間リンクの自動変換
CrossSiteLinkという仕掛け
設定管理と並んで運用を支えているのが、サイト間リンクの自動変換です。開発者が普通のリンクを書くだけで、それがSSO付きのリンクに自動で切り替わる仕組みを用意しました。
書く側は意識しなくていい
別サイトへのリンクを専用コンポーネント（CrossSiteLink）で書くと、宛先が有効サイトリストに載っているサイトなら、自動的にハンドオフを挟むリンクへ変換されます。開発者は「どこがSSO対象か」をいちいち覚えなくてよく、設定さえ正しければ勝手に正しく振る舞います。
これにより、SSOの適用漏れ（本来引き継ぐべきリンクなのに素のリンクになっていた、という事故）を防げます。人の注意力に頼らず、仕組みで正しさを担保するという発想です。
設定とリンクの連動
このCrossSiteLinkが参照するのも、先ほどの有効サイトリストです。つまり設定を一箇所直せば、トークンの発行・検証だけでなく、リンクの変換挙動までまとめて追従します。
設定を「唯一の真実の源（single source of truth）」にしておくことで、ある場所では新サイトが認識されているのに別の場所では未対応、といった不整合が起きにくくなります。設定管理とリンク変換が同じ名簿を見ている、この一貫性が運用の安心感につながっています。
まとめ
サイト追加に耐えるSSOのカギは、「変わりやすいものを設定へ追い出す」ことに尽きました。振り返ると次のとおりです。
- 3つの設定：署名シークレット・有効サイトリスト・コールバックURLを外出しする
- コードに直書きしない：サイトの顔ぶれとSSOの仕組みを分離する
- 対称な設計：全サイトが同じ仕組みを備え、設定を配れば仲間入りできる
- リンクも設定連動：CrossSiteLinkが同じ名簿を参照し、適用漏れを防ぐ
SSO全体の位置づけは「複数ECサイト間のシングルサインオン設計」に、トークンそのものの設計は「署名付きハンドオフトークンの仕組み」に、受け取った側の処理は「SSOコールバックとセッション確立のフロー」にまとめています。