單點登錄（SSO）實現(xiàn)詳解！！！

普通登錄

提到單點登錄，首先可以想到傳統(tǒng)登錄，通過登錄頁面根據(jù)用戶名查詢用戶信息，判斷密碼是否正確，正確則將用戶信息寫到session，訪問的時候通過從session中獲取用戶信息，判斷是否已登錄，登錄則允許訪問。

普通登錄的缺點

由于session不能共享，服務(wù)越來越多，并且還服務(wù)還搭建集群，導(dǎo)致每訪問另外一個服務(wù)都需要重新登錄。

單點登錄

單點登錄有個簡稱是sso，它是一個功能可以控制多個有聯(lián)系的系統(tǒng)操作，簡單地理解為通過單點登錄可以讓用戶只需要登錄一次軟件或者系統(tǒng)，那么同系統(tǒng)下的平臺都可以免去再次注冊、驗證、訪問權(quán)限的麻煩程序，通俗易懂的理解為一次性登錄也可以一次性下線。

前端需要知道的單點登錄概述：

1、一個系統(tǒng)登錄流程：用戶進入系統(tǒng)——未登錄——跳轉(zhuǎn)登錄界面——用戶名和密碼發(fā)送——服務(wù)器端驗證后，設(shè)置一個cookie發(fā)送到瀏覽器，設(shè)置一個session存放在服務(wù)器——用戶再次請求（帶上cookie）——服務(wù)器驗證cookie和session匹配后，就可以進行業(yè)務(wù)了。

2、多個系統(tǒng)登錄：如果一個大公司有很多系統(tǒng)，a.seafile.com, b.seafile.com,c.seafile.com。這些系統(tǒng)都需要登錄，如果用戶在不同系統(tǒng)間登錄需要多次輸入密碼，用戶體驗很不好。所以使用 SSO (single sign on) 單點登錄實現(xiàn)。

3、相同域名，不同子域名下的單點登錄：在瀏覽器端，根據(jù)同源策略，不同子域名的cookie不能共享。所以設(shè)置SSO的域名為根域名。SSO登錄驗證后，子域名可以訪問根域名的 cookie，即可完成校驗。在服務(wù)器端，可以設(shè)置多個子域名session共享（Spring-session）

4、不同域名下的單點登錄：CAS流程：用戶登錄子系統(tǒng)時未登錄，跳轉(zhuǎn)到 SSO 登錄界面，成功登錄后，SSO 生成一個 ST （service ticket ）。用戶登錄不同的域名時，都會跳轉(zhuǎn)到 SSO，然后 SSO 帶著 ST 返回到不同的子域名，子域名中發(fā)出請求驗證 ST 的正確性（防止篡改請求）。驗證通過后即可完成不同的業(yè)務(wù)。

單點登錄需求

在項目初期，公司中使用的系統(tǒng)很少，通常一個或者兩個，每個系統(tǒng)都有自己的登錄系統(tǒng)，用戶用自己的賬號登錄，很方便。

但隨著公司的不斷發(fā)展，用到的系統(tǒng)隨之增多，用戶在操作不同的系統(tǒng)時，需要多次登錄，而且每個系統(tǒng)的賬號都不一樣，這對于用戶來說，是很不好的體驗。于是，就想到是不是可以在一個系統(tǒng)登錄，其他系統(tǒng)就不用登錄了呢？這就是單點登錄要解決的問題。

單點登錄英文全稱Single Sign On，簡稱就是SSO。它的解釋是：在多個應(yīng)用系統(tǒng)中，只需要登錄一次，就可以訪問其他相互信任的應(yīng)用系統(tǒng)。

單點登錄（Single Sign On），簡稱為 SSO，是比較流行的企業(yè)業(yè)務(wù)整合的解決方案之一。SSO的定義是在多個應(yīng)用系統(tǒng)中，用戶只需要登錄一次就可以訪問所有相互信任的應(yīng)用系統(tǒng)。

如圖所示，圖中有4個系統(tǒng)，分別是Application1、Application2、Application3、和SSO。Application1、Application2、Application3沒有登錄模塊，而SSO只有登錄模塊，沒有其他的業(yè)務(wù)模塊，當(dāng)Application1、Application2、Application3需要登錄時，將跳到SSO系統(tǒng)，SSO系統(tǒng)完成登錄，其他的應(yīng)用系統(tǒng)也就隨之登錄了。這完全符合我們對單點登錄（SSO）的定義。

SSO 機制實現(xiàn)流程

用戶首次訪問時，需要在認(rèn)證中心登錄：

1. 用戶訪問網(wǎng)站 a.com 下的 pageA 頁面。
2. 由于沒有登錄，則會重定向到認(rèn)證中心，并帶上回調(diào)地址 （http://www.sso.com?return_uri=a.com/pageA%EF%BC%8C%E4%BB%A5%E4%BE%BF%E7%99%BB%E5%BD%95%E5%90%8E%E7%9B%B4%E6%8E%A5%E8%BF%9B%E5%85%A5%E5%AF%B9%E5%BA%94%E9%A1%B5%E9%9D%A2%E3%80%82 ）
3. 用戶在認(rèn)證中心輸入賬號密碼，提交登錄。
4. 認(rèn)證中心驗證賬號密碼有效，然后重定向 a.com?ticket=123 帶上授權(quán)碼 ticket，并將認(rèn)證中心 sso.com 的登錄態(tài)寫入 Cookie。
5. 在 a.com 服務(wù)器中，拿著 ticket 向認(rèn)證中心確認(rèn)，授權(quán)碼 ticket 真實有效。
6. 驗證成功后，服務(wù)器將登錄信息寫入 Cookie（此時客戶端有 2 個 Cookie 分別存有 a.com 和 sso.com 的登錄臺）。

認(rèn)證中心登錄完成之后，繼續(xù)訪問 a.com 下的其他頁面：

這個時候，由于 a.com 存在已登錄的 Cookie 信息，所以服務(wù)器端直接認(rèn)證成功。

如果認(rèn)證中心登錄完成之后，訪問 b.com 下的頁面：

這個時候，由于認(rèn)證中心存在之前登錄過的 Cookie，所以也不用再次輸入賬號密碼，直接返回第 4 步，下發(fā) ticket 給 b.com 即可。

SSO 機制實現(xiàn)方式

單點登錄主要有三種實現(xiàn)方式：

1. 父域 Cookie
2. 認(rèn)證中心
3. LocalStorage 跨域

一般情況下，用戶的登錄狀態(tài)是記錄在 Session 中的，要實現(xiàn)共享登錄狀態(tài)，就要先共享 Session，但是由于不同的應(yīng)用系統(tǒng)有著不同的域名，盡管 Session 共享了，但是由于 SessionId 是往往保存在瀏覽器 Cookie 中的，因此存在作用域的限制，無法跨域名傳遞，也就是說當(dāng)用戶在 a.com 中登錄后，Session Id 僅在瀏覽器訪問 a.com 時才會自動在請求頭中攜帶，而當(dāng)瀏覽器訪問 b.com 時，Session Id 是不會被帶過去的。實現(xiàn)單點登錄的關(guān)鍵在于，如何讓 Session Id（或 Token）在多個域中共享。

1. 父域 Cookie

Cookie 的作用域由 domain 屬性和 path 屬性共同決定。domain 屬性的有效值為當(dāng)前域或其父域的域名/IP地址，在 Tomcat 中，domain 屬性默認(rèn)為當(dāng)前域的域名/IP地址。path 屬性的有效值是以“/”開頭的路徑，在 Tomcat 中，path 屬性默認(rèn)為當(dāng)前 Web 應(yīng)用的上下文路徑。

如果將 Cookie 的 domain 屬性設(shè)置為當(dāng)前域的父域，那么就認(rèn)為它是父域 Cookie。Cookie 有一個特點，即父域中的 Cookie 被子域所共享，也就是說，子域會自動繼承父域中的 Cookie。

利用 Cookie 的這個特點，可以將 Session Id（或 Token）保存到父域中就可以了。我們只需要將 Cookie 的 domain 屬性設(shè)置為父域的域名（主域名），同時將 Cookie 的 path 屬性設(shè)置為根路徑，這樣所有的子域應(yīng)用就都可以訪問到這個 Cookie 了。不過這要求應(yīng)用系統(tǒng)的域名需建立在一個共同的主域名之下，如 tieba.baidu.com 和 map.baidu.com，它們都建立在 baidu.com 這個主域名之下，那么它們就可以通過這種方式來實現(xiàn)單點登錄。

總結(jié)：此種實現(xiàn)方式比較簡單，但不支持跨主域名。

2. 認(rèn)證中心

我們可以部署一個認(rèn)證中心，認(rèn)證中心就是一個專門負(fù)責(zé)處理登錄請求的獨立的 Web 服務(wù)。

用戶統(tǒng)一在認(rèn)證中心進行登錄，登錄成功后，認(rèn)證中心記錄用戶的登錄狀態(tài)，并將 Token 寫入 Cookie。（注意這個 Cookie 是認(rèn)證中心的，應(yīng)用系統(tǒng)是訪問不到的）

應(yīng)用系統(tǒng)檢查當(dāng)前請求有沒有 Token，如果沒有，說明用戶在當(dāng)前系統(tǒng)中尚未登錄，那么就將頁面跳轉(zhuǎn)至認(rèn)證中心進行登錄。由于這個操作會將認(rèn)證中心的 Cookie 自動帶過去，因此，認(rèn)證中心能夠根據(jù) Cookie 知道用戶是否已經(jīng)登錄過了。如果認(rèn)證中心發(fā)現(xiàn)用戶尚未登錄，則返回登錄頁面，等待用戶登錄，如果發(fā)現(xiàn)用戶已經(jīng)登錄過了，就不會讓用戶再次登錄了，而是會跳轉(zhuǎn)回目標(biāo) URL ，并在跳轉(zhuǎn)前生成一個 Token，拼接在目標(biāo) URL 的后面，回傳給目標(biāo)應(yīng)用系統(tǒng)。

應(yīng)用系統(tǒng)拿到 Token 之后，還需要向認(rèn)證中心確認(rèn)下 Token 的合法性，防止用戶偽造。確認(rèn)無誤后，應(yīng)用系統(tǒng)記錄用戶的登錄狀態(tài)，并將 Token 寫入 Cookie，然后給本次訪問放行。（這個 Cookie 是當(dāng)前應(yīng)用系統(tǒng)的，其他應(yīng)用系統(tǒng)是訪問不到的）當(dāng)用戶再次訪問當(dāng)前應(yīng)用系統(tǒng)時，就會自動帶上這個 Token，應(yīng)用系統(tǒng)驗證 Token 發(fā)現(xiàn)用戶已登錄，于是就不會有認(rèn)證中心什么事了。

總結(jié)：此種實現(xiàn)方式相對復(fù)雜，支持跨域，擴展性好，是單點登錄的標(biāo)準(zhǔn)做法。

3. LocalStorage 跨域

單點登錄的關(guān)鍵在于，如何讓 Session Id（或 Token）在多個域中共享。但是 Cookie 是不支持跨主域名的，而且瀏覽器對 Cookie 的跨域限制越來越嚴(yán)格。

在前后端分離的情況下，完全可以不使用 Cookie，我們可以選擇將 Session Id （或 Token ）保存到瀏覽器的 LocalStorage 中，讓前端在每次向后端發(fā)送請求時，主動將 LocalStorage 的數(shù)據(jù)傳遞給服務(wù)端。這些都是由前端來控制的，后端需要做的僅僅是在用戶登錄成功后，將 Session Id （或 Token ）放在響應(yīng)體中傳遞給前端。

在這樣的場景下，單點登錄完全可以在前端實現(xiàn)。前端拿到 Session Id （或 Token ）后，除了將它寫入自己的 LocalStorage 中之外，還可以通過特殊手段將它寫入多個其他域下的 LocalStorage 中。

總結(jié)：此種實現(xiàn)方式完全由前端控制，幾乎不需要后端參與，同樣支持跨域。

SSO 單點登錄退出

目前我們已經(jīng)完成了單點登錄，在同一套認(rèn)證中心的管理下，多個產(chǎn)品可以共享登錄態(tài)。現(xiàn)在我們需要考慮退出了，即：在一個產(chǎn)品中退出了登錄，怎么讓其他的產(chǎn)品也都退出登錄？

原理其實不難，可以在每一個產(chǎn)品在向認(rèn)證中心驗證 ticket(token) 時，其實可以順帶將自己的退出登錄 api 發(fā)送到認(rèn)證中心。

當(dāng)某個產(chǎn)品 c.com 退出登錄時：

清空 c.com 中的登錄態(tài) Cookie。請求認(rèn)證中心 sso.com 中的退出 api。認(rèn)證中心遍歷下發(fā)過 ticket(token) 的所有產(chǎn)品，并調(diào)用對應(yīng)的退出 api，完成退出。

作者：愛吃橘子的程序猿  https://juejin.cn/post/7282692430117748755

• Node 社群

我組建了一個氛圍特別好的 Node.js 社群，里面有很多 Node.js小伙伴，如果你對Node.js學(xué)習(xí)感興趣的話（后續(xù)有計劃也可以），我們可以一起進行Node.js相關(guān)的交流、學(xué)習(xí)、共建。下方加 考拉 好友回復(fù)「Node」即可。

• 
  

• 最后不要忘了點個贊再走噢