クロスドメインセッションの標準化
クロスドメインセッションを調査しています。これらは、google.comとspotify.comのような2つのドメイン間で共有されるセッションです。サブドメイン間のクロスドメインセッションに関する情報は探していません。セッションIDを保持するCookieのスコープを広げることで共有できるためです。そのため、play.google.comとmail.google.comは同じセッションを簡単に共有でき、このセッション共有には複雑なset uリダイレクトやajax呼び出しは必要ありません。
このようなクロスドメインセッションの設定に正式な基準があるかどうか知りたいのですが。すべてのフレームワークが独自のメカニズムを持っているかのように見えます。それらの多くはリダイレクトを使用しており、その他はJavaScriptを使用しています。このドメインでの研究の一環として、これらのクロスドメインセッションを実現するために広く使用されている標準と見なすことができるものを探しています。また、非公式の標準（広く使用されているメカニズム）に関する情報も高く評価されています。
ニールの答えに基づいて編集：私は確かに私の推論に間違いを犯したことがわかりました。 SSOに必要なのはクロスドメインセッションではなく、実際にはクロスドメイン状態です。私が間違っている場合は修正してください。ただし、サーバーがCookieが有効なドメインのホワイトリストを提供できる場合は、セキュリティ上の問題がなければ、SSOははるかに単純になります。すべての認証情報（uid、roles、idpなど）を使用してCookieを作成し、このCookieをSSO sopeに含めるすべてのドメイン間で共有するだけです。最初のドメインがこのドメインのCookieを設定できるようにする場合、ホワイトリストの他のドメインをチェックするメカニズムを組み込む必要があります。
私はあなたの方言について少し混乱しています。でもやってみます。
シングルサインオン （SSO）を指すために「セッション」という言葉を使用していると思います。これは、1つのサイトにサインインして、再認証を必要とせずにそのサインオンを他のサイトに伝達できるようにする機能です。これにはいくつかの基準があります。それらは OAuth を含みます1、 [〜＃〜] saml [〜＃〜] 、および OpenID Connect 。
SSOは共有セッションと同じではありません。共有セッションは認証を超えた共有状態を意味しますが、SSOは認証にのみ影響します。ブラウザーのセキュリティ機能により、複数のWebサイト間で状態を共有することは困難な傾向があります same-Originポリシー おそらく最大です。 supercookies やFlash Cookieなどの機能は共有セッションの実装に使用されることがありますが、ブラウザのセキュリティ保護のため、機能が非常に制限される傾向があります。
あなたがGoogleとSpotifyに与えた例に関して、彼らはセッションを共有しません。代わりに、OAuthを使用して、Googleログインを使用して新しいSpotifyアカウントを作成できるようにします。いったん作成すると、アカウントは切断されます。たとえば、1つのサービスからログアウトしても、ログアウトされませんもう一つの。
1技術的には、OAuthは認証プロトコルですが、しばしばSSOのように見えます。