早上用戶反饋了一個比較嚴重的問題，系統無法登錄了。異常信息如下：
首先系統已經正常運行了兩個多月，登錄這種問題一般會暴露地很快，而且上線後一般不會修改相關邏輯，查看 Git 記錄，並未修改相關代碼；隨後也排除了認證系統的問題，因爲如果認證系統出現問題，那整個公司都會受到影響，而並沒有其他系統並沒有相關反饋。通過進一步向用戶詢問，獲得如下信息：
-
最近纔出現；
-
瀏覽器均使用的 Chrome 80 版本；
在灰度和線上環境的復現：
正常登錄 http://a.com 後，再直接訪問 http://b.com，頁面出現異常：
然後切換瀏覽器、降低 Chrome 版本進行測試，總結如下信息：
-
只有 Chrome 80 及以上版本會出現問題，其他瀏覽器沒有這個問題；
-
出現問題的系統是 HTTP，暫未升級到 HTTPS；HTTPS 系統正常；
於是查看了 Chrome 的更新日誌，找到如下信息：
Updates to cookies with SameSite
Starting in Chrome 80, cookies that don’t specify a SameSite attribute will be treated as if they were SameSite=Lax. Cookies that still need to be delivered in a cross-site context can explicitly request SameSite=None. Cookies with SameSite=None must also be marked Secure and delivered over HTTPS. To reduce disruption, the updates will be enabled gradually, so different users will see it at different times. We recommend that you test critical sites using the instructions for testing.
You will be able to revert to the legacy cookie behavior using policies until Chrome 88. You can specify trusted domains using LegacySameSiteCookieBehaviorEnabledForDomainList or control the
1 global default with LegacySameSiteCookieBehaviorEnabled. For more details, visit Cookie Legacy SameSite Policies.
首先 Cookie 默認的 Samesite 設置爲了 Lax，如果需要跨站傳遞 Cookie，需要指定 SameSite 爲 None，標記 Secure（通過 HTTPS 傳遞）。
到這裏其實就很清晰了，公司的 SSO 都是通過 Cookie 去管理 Token，由於 Samesite 默認設置爲了 Lax ，我們這裏的第三方 Cookie 是 SameSite=None; Secure 的。訪問系統跳轉到 SSO 的時候，由於不是 HTTPS 所以 SSO 無法下發 Token（STS），從而出現：訪問系統 -> 302 -> 登錄成功 -> 訪問系統 -> 302 的情況，即重定向次數過多。
知道原因後就很好解決了，升級爲 HTTPS 即可。