主要是學習了這篇微博：https://www.cnblogs.com/EzrealLiu/p/5559255.html
這篇文章在方案3和方案4中講解的個人有點不理解，加了一點自己的理解

原文

1.U第一次訪問W，W驗證失敗，跳轉至SSO要求U進行登入驗證；
登入並使各不同Domain下：
2.U 給SSO傳送登入請求，SSO驗證成功，生成SessionID 並儲存UserInfo；
返回給U的Response 將 UserInfo 存放至cookie中，Domain為SD；/*個人覺得這裡可以將SessionID放入cookie也可以，之後在快取中獲取即可*/
3.將 2 中 cookie 內容作為query parameter 重定向至T，T驗證後成功返回給U，也在Response 中設定 cookie；Domain為TD；
4.U
 
自動訪問SSO，SSO將請求重定向至W，完成U對W 的訪問；
5.U 再訪問 T，驗證成功並允許U進行訪問；

這裡我們要注意，方案三主要將UserInfo寫入之後直接訪問T的瀏覽器的快取中，這時候U不用在經過SSO這一層了，因為cookie中已經有了UserInfo的資訊。而在方案4中則相反。這點要非常注意，也是理解的關鍵。

下面看方案4，方案4是為了對方案三的所有回寫的一個改進，每次訪問才做回寫，解決了方案3的卡頓問題

1.使用者U訪問W ，W進行驗證，驗證失敗，跳轉至SSO，要求U登入；
2.U通過SSO登入，SSO進行驗證，成功並生成SessionID，隨後將UserInfo（ SessionID、ID和口令）儲存到公共快取C 中，跳轉至W（攜帶SessionID），並允許U訪問W；U儲存UserInfo （ SessionID ） 至 cookie；
3.
 
U訪問T，T 進行驗證，失敗跳轉至SSO，SSO將觸發U請求SSO將驗證資訊隨請求一併發給SSO，經SSO驗證成功跳轉至Ｔ，允許U對T 的訪問；使U儲存UserInfo（ SessionID）至cookie；

這裡我們會發現，U在訪問T的時候和方案3完全不同，方案3是直接訪問T不用經過SSO層，這裡需要經過SSO層？為什麼呢？因為U在訪問W的時候將SessionID寫入了SSO層的cookie中，所以當我們U訪問T時，我們將請求直接轉到SSO層，利用SSO層的cookie實現系統的登陸。明白這一點很關鍵。

這兩個方案的主要區別就在於，訪問第二個跨域站點時，方案3入口是直接的第二個站點T，方案4入口其實不是第二個站點T，而是SSO這一層。