Cookie的secure屬性引起循環登錄問題分析及解決方案详情 - 單點登錄,cookie,https vivo互聯網技術日志

作者：來自 vivo 互聯網服務器團隊- Wang Fei

單點登錄作為公共組件，在各個公司內部被各個系統所廣泛使用，但是在使用過程中我們會遇到各種各樣的問題，其中循環登錄問題就是一個比較經典的問題。本文主要分析單點登錄和權限系統設計的基本原理，然後結合實際案例來分析循環登錄的原因，並給出具體的解決辦法。

一、單點登錄簡單介紹

1.1 基本概念

一個公司內部可能存在多個系統，如果每一個人在使用不同系統的時候都需要重新登錄，那麼會做大量系統登錄切換、耗費比較多的精力去管理賬號和密碼，那麼有沒有辦法在一個公司內部的所有系統只需要一次登錄驗證，後續使用其他系統的時候不用重複登錄就可以直接使用呢，這就是單點登錄要解決的問題。

單點登錄英文全稱 Single Sign On（SSO），允許用户一次登錄即可訪問多個應用程序或系統，無需為每個應用程序或系統分別輸入認證憑據，便可在其他所有系統中得到授權，無需再次登錄。

1.2 基本實現原理

用户登錄：用户在任何一個應用程序或系統中進行身份驗證，並提供他們的憑據。
認證系統驗證：該憑據被髮送到認證系統進行驗證。如果憑據有效，則認證系統會為用户生成數字簽名的令牌（如 Token 或 Ticket）。
令牌分發：認證系統將令牌返回給應用程序或子系統。
應用程序或系統授權：應用程序或系統使用令牌驗證用户的身份，並授權其訪問相應資源或服務。
跨域系統訪問：用户可以通過同一令牌訪問多個跨域應用程序或系統，而無需重複進行身份驗證。

二、循環登錄問題

在某一天我們登錄一個內部系統時，突然出現了循環登錄問題，前端頁面不斷刷新，提示“重定向次數過多問題”。

打開前端調試功能, 我們會發現確實存在大量重定向請求的問題：

那麼平時登錄沒問題的系統為什麼突然間就循環登錄呢？並在頁面上提示的解決方法“嘗試刪除您的 Cookie 操作”，按照這個操作以後，確實系統又可以跳轉到登錄頁面正常進行登錄了，這又是什麼原因？下面我們將逐一分析。

三、從一次正常登錄流程説起

上述是一個通用的系統權限管控和單點系統認證的標準流程：

用户第一次訪問時，在瀏覽器輸入 https://aaa.x.y 回車
權限系統進行攔截，判斷用户是否登錄，這裏主要是通過是否有登錄信息判斷，如果沒有登錄，權限系統會幫我們跳轉到單點登錄系統，彈出用户登錄頁。
用户填寫用户名、密碼，單點登錄系統進行認證後，將登錄狀態寫入 SSO 的 session。
SSO 系統登錄完成後會給我們的系統生成一個 Token ，然後跳轉到我們的系統，同時將 Token 作為參數傳遞給我們的系統。
我們系統拿到 Token 後，從後台向 SSO 發送請求，驗證 Token 是否有效。
驗證通過後，我們系統將記錄頂級域下的 Cookie 信息。

Connection: keep-alive
Content-Length: 0
Date: Wed, 25 Oct 2023 08:29:43 GMT
Location: http://aaa.x.y/console/login/auth?redirectUrl=http://aaa.x.y/
optrace: xx.xx.xx.xx:80/302 <- -
Server: nginx
Set-Cookie: token=fakdfajdfdjfdjkfaldfjk'afafjasfasfa; Max-Age=86400; Expires=Thu, 26-Oct-2023 08:29:43 GMT; Domain=x.y; Path=/; HttpOnly

一個公司內部一般情況下只有一個域名，通過二級域名區分不同的系統。比如我們有個域名叫做：x.y ，同時有兩個業務系統分別為：app1.x.y 和 app2.x.y。SSO 登錄以後，可以將 Cookie 的域設置為頂域，即 x.y ，這樣所有子域的系統都可以訪問到頂域的 Cookie，實現單點登錄功能。

四、循環登錄產生的根本原因

那麼為什麼會不斷循環登錄呢？

（1）從跳轉記錄來看，我們發現重新刷新頁面以後，重定向到了權限系統，並且 Request Headers 中的 Cookie 信息沒有傳對應的 Token 信息。

（2）跳轉到權限系統過後，再跳轉到本系統的時候，已經獲取到了對應的 Token 信息，但是在 Set-Cookie 信息的時候，出現了一個警告。

警告的具體內容為：

大致意思是：這次執行 Set-Cookie 操作被阻止了，原因是這個 Cookie 不是通過安全的連接進行傳輸的，我們這次訪問確實使用了 HTTP 進行，本應該通過設置 Secure 屬性來覆蓋對應的 Cookie。

這裏的 Secure 屬性是 Cookie 的一個屬性，Secure 屬性是説如果一個 Cookie 被設置了 Secure = true，那麼這個 Cookie 只能用 HTTPS 協議發送給服務器，用 HTTP 協議是不發送的，而我們查看上面標註位置的下一個 Login 請求確實沒有傳 Cookie 信息，從而繼續進行用户是否登錄校驗，進入死循環過程，可以看下面的示意圖:

五、清除瀏覽器緩存的底層原理及解決方法

5.1 清除瀏覽器緩存的底層原理

我們可以看到循環登錄以後，會在瀏覽器頁面上提示 xxx.x.y 重定向次數過多，嘗試清除 Cookie 信息，那清除 Cookie 信息以後，是不是真的就可以解決這個問題呢，我們嘗試着清除瀏覽器緩存，確實可以解決這個問題，那清除瀏覽器緩存來解決循環登錄問題的底層原理是什麼呢，其實質就是將 Cookie 刪除，其他域名設置 Cookie 上的 Secure 屬性也就一併刪除了，從而使用 HTTP 域名進入重新登錄流程，可以正常設置 Cookie 信息。

5.2 其他解決辦法

方法一：使用 HTTPS 的方式進行訪問
現實使用中，我們無法控制其他 HTTPS 訪問的具有相同頂級域名的服務不去設置 Cookie 的 Secure 屬性，因而我們在後面使用的過程中還是會遇到這個問題，那麼有沒有一種徹底的解決辦法能夠避免這個問題再次出現，我們前面已經分析，之所以我們在開始使用 HTTP 能夠進行正常訪問，然後突然間不能正常訪問了，就是因為已經被 HTTPS 設置了的 Cookie 信息是無法被 HTTP 重新設置的，從而拿不到 Cookie 信息。那麼就出現了第一種解決辦法，使用 HTTPS 的方式進行訪問，即使其他服務設置了 Cookie 的 Secure 屬性，用 HTTPS 仍然能夠成功設置 Cookie 和獲取 Cookie。

方法二：在 Cookie 信息中新設置一個 newToken
以上從 HTTP 轉為 HTTPS 訪問的方法在用户主動找我們反饋時是能夠告訴它切換為 HTTPS 訪問的，但是如果對於一些沒有主動找我們反饋的用户，其實是無法解決，可能喪失這個用户造成用户流失的情況，那麼我們在用户不進行切換的情況下是否能夠解決這個問題。

同一個公司內部接入的權限系統是一種底層公共能力，為了保證單點登錄，其實用户信息的讀取都是通過同一個 Cookie 參數（比如叫 Token ）讀取的，那麼在其他域名設置了公共 Cookie 參數的 Secure 屬性而影響到 HTTP 登錄的時候，我們可以給服務新增加一個 Cookie 參數 newToken 去解決。

六、擴展: Cookie 的端口不隔離性

本文所闡述的問題，出現的背景是有兩個基本前提的：一是為了保證單點登錄，兩個域名屬於同一個頂級域名，權限系統中關於用户信息的校驗都是通過同一個 Cookie 屬性去讀取的；第二個是 HTTPS 設置了頂級域名的 Cookie 信息的 Secure 屬性，然後使用 HTTP 訪問會導致循環登錄。有些開發者可能會有這樣一個疑問，那就是 HTTPS 我們一般開通的端口是 443 ， HTTP 我們一般開通的端口是 8080 ，為啥不從端口上進行區分同一個 Cookie 屬性從而避免干擾呢？

這個在 Cookie 規範（RFC 6265）中有所描述，那就是 Cookie 不提供通過端口進行隔離的，也就是説如果一個 Cookie 可以被一台服務器上的運行在某一個端口上的一個服務所讀取，那麼也可以被這台服務器上運行在另外一個端口上的服務所讀取；如果一個 Cookie 可以被一台服務器上的運行在某一個端口上的一個服務所寫入，那麼也可以被這台服務器上運行在另外一個端口上的服務所寫入。