圖文並茂，爲你揭開「單點登陸「的神祕面紗

原創不易，但願能關注下咱們，再順手點個贊~~

本文首發於政採雲前端團隊博客： 圖文並茂，爲你揭開「單點登陸「的神祕面紗

概念

單點登陸( Single Sign On ，簡稱 SSO），是目前比較流行的企業業務整合的解決方案之一，用於多個應用系統間，用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。

前置介紹

1. 同源策略 限制了從同一個源加載的文檔或腳本如何與來自另外一個源的資源進行交互，要求協議，端口和主機都相同。
2. HTTP 用於分佈式、協做式和超媒體信息系統的應用層協議。HTTP 是無狀態協議，因此服務器單從網絡鏈接上無從知道客戶身份。 那要如何才能識別客戶端呢？給每一個客戶端頒發一個通行證，每次訪問時都要求帶上通行證，這樣服務器就能夠根據通行證識別客戶了。最多見的方案就是 Cookie。
3. Cookie 是客戶端保存用戶信息的一種機制，保存在客戶機硬盤上。能夠由服務器響應報文Set-Cookie的首部字段信息或者客戶端 document.cookie來設置，並隨着每次請求發送到服務器。子域名能夠獲取父級域名 Cookie。
4. Session 實際上是一個抽象概念，用於跟蹤會話，識別屢次 HTTP 請求來自同一個客戶端。Cookie 只是通用性較好的一種實現方案，一般是設置一個名爲 SessionID（名稱可自定義，便於描述，本文均使用此名稱）的 Cookie，每次請求時攜帶該 Cookie，後臺服務便可依賴此 SessionID 值識別客戶端。

單系統登陸

在介紹單點登陸以前，咱們先來了解一下在瀏覽器中，訪問一個須要登陸的應用時主要發生的一系列流程，以下圖所示：

如下爲連環畫形式，指望能讓讀者更好的理解：

依賴於登陸後設置的 Cookie，以後每次訪問時都會攜帶該 Cookie，從而讓後臺服務能識別當前登陸用戶。

題外話

後臺是如何經過 SessionID 知道是哪一個用戶呢？

1. 數據庫存儲關聯：將 SessionID 與數據信息關聯，存儲在 Redis、mysql 等數據庫中；
2. 數據加密直接存儲：好比 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

若是隻是指望異步請求時獲取當前用戶的登陸態，能夠經過發送跨域請求到已經登陸過的域名，並配置屬性：

xhrFields: {
  withCredentials: true
}
複製代碼

這樣可在請求時攜帶目標域名的 Cookie，目標域名的服務便可識別當前用戶。

可是，這要求目標域名的接口支持 CORS 訪問（出於安全考慮，CORS 開啓 withCredentials 時，瀏覽器不支持使用通配符*，需明確設置可跨域訪問的域名名單）。

題外話：

若是隻是爲了規避瀏覽器的限制，實現與通配*一樣的效果，到達全部域名均可以訪問的目的，可根據訪問的 Referrer 解析請求來源域名，做爲可訪問名單。可是出於安全考慮，不推薦使用，請設置明確的可訪問域名。

CAS

CAS（Central Authentication Service），即中央認證服務，是 Yale 大學發起的一個開源項目，旨在爲 Web 應用系統提供一種可靠的單點登陸方法。

既然不能跨域獲取，那 CAS 如何作到共享呢？它經過跳轉中間域名的方式來實現登陸。

頁面訪問流程以下圖：

如下爲連環畫形式，指望能讓讀者更好的理解：

其中須要關注如下 2 點：

1. 全部的登陸過程都依賴於 CAS 服務，包含用戶登陸頁面、ST 生成、驗證；
2. 爲了保證 ST 的安全性，通常 ST 都是隨機生成的，沒有規律性。CAS 規定 ST 只能保留必定的時間，以後 CAS 服務會讓它失效，並且，CAS 協議規定 ST 只能使用一次，不管 ST 驗證是否成功，CAS 服務都會清除服務端緩存中的該 ST，從而規避同一個 ST 被使用兩次或被竊取的風險。

擴展閱讀

其餘相關的內容，也能夠進行簡單瞭解，如：單點登陸退出 SLO、OAuth2。

參考文檔

瀏覽器的同源策略

CAS 協議

招賢納士

政採雲前端團隊（ZooTeam），一個年輕富有激情和創造力的前端團隊，隸屬於政採雲產品研發部，Base 在風景如畫的杭州。團隊現有 50 餘個前端小夥伴，平均年齡 27 歲，近 3 成是全棧工程師，妥妥的青年風暴團。成員構成既有來自於阿里、網易的「老」兵，也有浙大、中科大、杭電等校的應屆新人。團隊在平常的業務對接以外，還在物料體系、工程平臺、搭建平臺、性能體驗、雲端應用、數據分析及可視化等方向進行技術探索和實戰，推進並落地了一系列的內部技術產品，持續探索前端技術體系的新邊界。

若是你想改變一直被事折騰，但願開始能折騰事；若是你想改變一直被告誡須要多些想法，卻無從破局；若是你想改變你有能力去作成那個結果，卻不須要你；若是你想改變你想作成的事須要一個團隊去支撐，但沒你帶人的位置；若是你想改變既定的節奏，將會是「 5 年工做時間 3 年工做經驗」；若是你想改變原本悟性不錯，但老是有那一層窗戶紙的模糊… 若是你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的本身。若是你但願參與到隨着業務騰飛的過程，親手推進一個有着深刻的業務理解、完善的技術體系、技術創造價值、影響力外溢的前端團隊的成長曆程，我以爲咱們該聊聊。任什麼時候間，等着你寫點什麼，發給 ZooTeam@cai-inc.com

推薦閱讀

1024 鉅獻！！一文看盡前端過去一年的精華沉澱（700 篇好文大彙總）

多是最全的 「文本溢出截斷省略」 方案合集

乾坤大挪移！React 也能 「用上」 computed 屬性