iframe / p3pのトリックが最も人気があると思いますが、javascript +非表示フィールド+フレームが実際にハックジョブのように見えるため、個人的には好きではありません。また、Webサービスを使用して通信するマスタースレーブアプローチ（ http://www.15seconds.com/issue/971108.htm ）にも出くわしました。これは、ユーザーに対して透過的であり、さまざまなブラウザーに対して堅牢であるため、より優れているようです。
より良いアプローチはありますか、そしてそれぞれの長所と短所は何ですか？
私のアプローチでは、1つのドメインを「中央」ドメインとして指定し、他のドメインを「衛星」ドメインとして指定します。
誰かが「サインイン」リンクをクリックすると（または永続的なログインCookieを提示すると）、サインインフォームは最終的に、中央ドメインにあるURLに、データがどのドメインから来たかを示す非表示のフォーム要素とともにデータを送信します（便宜上、ユーザーは後でリダイレクトされます）。
次に、中央ドメインのこのページは、セッションCookieの設定に進み（ログインがうまくいった場合）、そのセッションに固有のURLに特別に生成されたトークンを使用して、ユーザーがログインしたドメインにリダイレクトします。
次に、サテライトURLのページは、そのトークンをチェックして、セッション用に生成されたトークンに対応しているかどうかを確認します。対応している場合は、トークンなしで自分自身にリダイレクトし、ローカルCookieを設定します。これで、サテライトドメインにもセッションCookieがあります。このリダイレクトにより、URLからトークンがクリアされるため、ユーザーまたはクローラーがそのトークンを含むURLを記録する可能性は低くなります（記録した場合でも、トークンは使い捨てトークンである可能性があります）。
これで、ユーザーは中央ドメインとサテライトドメインの両方でセッションCookieを使用できます。しかし、彼らが別の衛星を訪問した場合はどうなるでしょうか。さて、通常、それらは認証されていないように衛星に見えます。
ただし、私のアプリケーション全体で、ユーザーが有効なセッションに参加しているときはいつでも、他のサテライトドメインのページへのすべてのリンクに？sまたは＆sが追加されます。この「s」クエリ文字列は、「このユーザーにはセッションがあると見なされるため、中央サーバーに確認する」ことを意味するように予約しています。つまり、どのHTMLページにもトークンまたはセッションIDは表示されず、誰かを識別できない文字「s」のみが表示されます。
このような「s」クエリタグを受信するURLは、有効なセッションがまだない場合、「これが誰であるかを教えてくれませんか」と言って中央ドメインにリダイレクトします。クエリ文字列に何かを入れることによって。
ユーザーが中央サーバーに到着したときに、そこで認証されている場合、中央サーバーは単にセッションCookieを受信します。次に、ユーザーを別の使い捨てトークンとともに衛星に送り返します。これは、衛星がログイン後と同じように処理します（上記を参照）。つまり、サテライトはそのドメインにセッションCookieを設定し、それ自体にリダイレクトしてクエリ文字列からトークンを削除します。
私のソリューションは、スクリプトやiframeのサポートなしで機能します。ユーザーがまだそのURLにCookieを持っていない可能性があるクロスドメインURLに「？s」を追加する必要があります。私はこれを回避する方法を考えました。ユーザーが最初にログインするときに、すべての単一ドメインの周りにリダイレクトのチェーンを設定し、各ドメインにセッションCookieを設定します。私がこれを実装していない唯一の理由は、これらのリダイレクトが発生する順序と停止するタイミングを設定できる必要があり、15ドメイン程度を超えて拡張できないという点で複雑になるためです。 （多すぎると、多くのブラウザやプロキシの「リダイレクト制限」に危険なほど近づきます）。
フォローアップメモ：これは11年前、ウェブが大きく異なっていたときに書かれました。たとえば、XMLhttprequestは、ドメイン間で信頼できるものとは見なされていませんでした。
すべてのドメインのバックエンドを完全に制御できる場合、これは良い解決策です。私の状況では、クライアント（javascript / html）コントロールしかなく、フルコントロールしかないため、iframe / p3pメソッドを使用する必要があります.
OK、解決策を見つけたようです。Cookieを設定/取得するドメインのsrcをロードするスクリプトタグを作成できます...これまでのところSafariのみがCookieを設定できないようですが、Ie6とFF正常に動作します...それでも、Cookie を取得するだけの場合、これは非常に優れたアプローチです。
@トーマスルッター
ページの読み込み時に「中央」ドメインの認証ステータスをチェックする ajax 呼び出しを行うことで、(クエリ文字列に「s」を追加することで) サテライトのすべてのアウトバウンド リンクを管理する必要がなくなります。セッションごとに 1 つだけ作成することで、(後続のページの読み込み時に) 冗長な呼び出しを回避できます。
(a) セッションへのより効率的なアクセスが可能であり、(b) ユーザーがログインしているかどうかをページのレンダリング時に知ることができるように、ページをロードする前に認証チェック要求をサーバー側で行う方が間違いなく優れています (それに応じてコンテンツを表示します）。
その記事の例は、基本的に URL にリダイレクトし、その URL が変数をクエリ文字列でドメインに返すため、疑わしいと思われます。
この例では、悪意のあるユーザーが単にhttp://slave.com/return.asp?Return=blah&UID=123に移動し、slave.com にユーザー 123 としてログインできることを意味します。
私は何かを見逃しているのでしょうか、それともこの手法は安全ではなく、その例が示唆するようなものに使用すべきではないことはよく知られています (おそらく ID を移植可能にするために、ユーザー ID を渡します)。
Cookie チェーンを使用していますが、ドメインの 1 つがユーザーに対して機能しない場合 (フィルタリング/ファイアウォールなどにより) 壊れるため、良い解決策ではありません。新しい技術 (あなたのものを含む) は、Cookie を配布したり、ログインを管理したりする「マスター」サーバーが壊れたときにのみ壊れます。
return.asp が悪用されて任意のサイトにリダイレクトされる可能性があることに注意してください (たとえば、これを参照してください)。
また、ドメイン b、c、d、... に対してアクティブなセッション情報を検証する必要があります。この方法では、ユーザーが既にドメイン a にログインしている場合にのみログインできます。
あなたがすることは、参照元アドレスもチェックする変数を受け取るドメイン上で、リンクが自分のドメインからのものであり、誰かが単にアドレスバーにリンクを入力するだけではないことを確認できるようにすることです. このアプローチはうまく機能します。