單點登錄( Single Sign On ，簡稱 SSO)，是目前比較流行的企業業務整合的解決方案之一，用於多個應用系統間，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。
圖片來自 Pexels
前置介紹：
- 同源策略，限制了從同一個源加載的文檔或腳本如何與來自另一個源的資源進行交互，要求協議，端口和主機都相同。
- HTTP 用於分佈式、協作式和超媒體信息系統的應用層協議。HTTP 是無狀態協議，所以服務器單從網絡連接上無從知道客戶身份。
- 那要如何才能識別客戶端呢?給每個客戶端頒發一個通行證，每次訪問時都要求帶上通行證，這樣服務器就可以根據通行證識別客戶了。最常見的方案就是 Cookie。
- Cookie 是客戶端保存用戶信息的一種機制，保存在客戶機硬盤上。可以由服務器響應報文 Set-Cookie 的首部字段信息或者客戶端 document.cookie來設置，並隨著每次請求發送到服務器。子域名可以獲取父級域名 Cookie。
- Session 其實是一個抽象概念，用於跟蹤會話，識別多次 HTTP 請求來自同一個客戶端。
- Cookie 只是通用性較好的一種實現方案，通常是設置一個名為 SessionID(名稱可自定義，便於描述，本文均使用此名稱)的 Cookie，每次請求時攜帶該 Cookie，後臺服務即可依賴此 SessionID 值識別客戶端。
單系統登錄
在介紹單點登錄之前，我們先來了解一下在瀏覽器中，訪問一個需要登錄的應用時主要發生的一系列流程，如下圖所示：
以下為連環畫形式，期望能讓讀者更好的理解：
依賴於登錄後設置的 Cookie，之後每次訪問時都會攜帶該 Cookie，從而讓後臺服務能識別當前登錄用戶。
題外話：後臺是如何通過 SessionID 知道是哪個用戶呢?
- 數據庫存儲關聯：將 SessionID 與數據信息關聯，存儲在 Redis、MySQL 等數據庫中。
- 數據加密直接存儲：比如 JWT 方式，用戶數據直接從 SessionID 值解密出來(此方式時 Cookie 名稱以 Token 居多)。
多系統登錄問題
同域名
當訪問同域名下的頁面時，Cookie 和單系統登錄時一樣，會正常攜帶，後臺服務即可直接獲取到對應的 SessionID 值，後臺為單服務還是多服務無差別。
不同子域名
子域名間 Cookie 是不共享的，但各子域名均可獲取到父級域名的 Cookie，即 app.demo.com與 news.demo.com均可以獲取 demo.com域名下的 Cookie。
所以可以通過將 Cookie 設置在父級域名上，可以達到子域名共享的效果，即當用戶在 app.demo.com 域名下登錄時，在demo.com域名下設置名為 SessionID 的 Cookie。
當用戶之後訪問news.demo.com時，後臺服務也可以獲取到該 SessionID，從而識別用戶。
完全不同域名
默認情況下，不同域名是無法直接共享 Cookie 的。
前端跨域帶 Cookie
如果只是期望異步請求時獲取當前用戶的登錄態，可以通過發送跨域請求到已經登錄過的域名，並配置屬性：
<code>xhrFields: { withCredentials: true } /<code>這樣可在請求時攜帶目標域名的 Cookie，目標域名的服務即可識別當前用戶。
但是，這要求目標域名的接口支持 CORS 訪問(出於安全考慮，CORS 開啟 withCredentials 時，瀏覽器不支持使用通配符*，需明確設置可跨域訪問的域名名單)。
題外話：如果只是為了規避瀏覽器的限制，實現與通配*同樣的效果，到達所有域名都可以訪問的目的，可根據訪問的 Referrer 解析請求來源域名，作為可訪問名單。但是出於安全考慮，不推薦使用，請設置明確的可訪問域名。
CAS
CAS(Central Authentication Service)，即中央認證服務，是 Yale 大學發起的一個開源項目，旨在為 Web 應用系統提供一種可靠的單點登錄方法。
既然不能跨域獲取，那 CAS 如何做到共享呢?它通過跳轉中間域名的方式來實現登錄。
頁面訪問流程如下圖：
以下為連環畫形式，期望能讓讀者更好的理解：
其中需要關注以下 2 點：
- 所有的登錄過程都依賴於 CAS 服務，包含用戶登錄頁面、ST 生成、驗證。
- 為了保證 ST 的安全性，一般 ST 都是隨機生成的，沒有規律性。
- CAS 規定 ST 只能保留一定的時間，之後 CAS 服務會讓它失效，而且，CAS 協議規定 ST 只能使用一次，無論 ST 驗證是否成功，CAS 服務都會清除服務端緩存中的該 ST，從而規避同一個 ST 被使用兩次或被竊取的風險。
閱讀更多 51CTO 的文章
