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