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