什么是單點登錄

單點登錄是指在多個應(yīng)用系統(tǒng)中，用戶只需要登錄任意一個系統(tǒng)，就可以訪問其他的互相信任的系統(tǒng)。比如說我在天貓登錄后，在瀏覽器上輸入淘寶的域名，你就已經(jīng)登錄成功了。

為什么需要單點登錄

為了方便，如果一款產(chǎn)品的用戶體驗很差勁，那么基本上是沒有用戶愿意持續(xù)使用的。

通過單點登錄，可以讓用戶在多系統(tǒng)中靈活跳轉(zhuǎn)而不必重新登錄，能有效提升用戶體驗。

常見的登錄實現(xiàn)

首先我們后端有個攔截器，每次請求接口時都會在攔截器內(nèi)部進行判斷：根據(jù)Cookie中傳遞的SessionId判斷用戶信息是否已經(jīng)保存在Session中。如果不存在，說明用戶未登錄，讓瀏覽器跳轉(zhuǎn)到登錄頁進行登錄。

登錄驗證成功后，把用戶信息寫入到 服務(wù)器Session中。于是通過Cookie中的SessionId和服務(wù)器建立了會話。

并且一般來說，瀏覽器中的Cookie不會設(shè)置過期時間，而是在服務(wù)端的Session中設(shè)置，由服務(wù)端來控制用戶的登錄態(tài)。

單點登錄的設(shè)計思路

首先我們要了解，單點登錄其實就是用戶的登錄態(tài)在多個系統(tǒng)間進行共享。我們可以這樣思考，假如用戶在 A系統(tǒng) 登錄后，然后點擊 B系統(tǒng)，能夠把用戶相關(guān)信息給帶過去，然后在 B系統(tǒng)中判斷存在用戶信息， 從而進行登錄。這樣做對于用戶來說是完全無感知的，只需要在系統(tǒng)層面幫助用戶進行登錄即可。

傳遞數(shù)據(jù)到前端還是后端

如果是通過瀏覽器頁面?zhèn)鬟f信息，前端拿到用戶信息后，可以調(diào)用 B系統(tǒng) 服務(wù)端接口進行登錄，與B系統(tǒng)建立會話。

如果是傳遞到 B系統(tǒng) 后端服務(wù)器，需要在服務(wù)器進行登錄，然后帶上用戶信息重定向到B系統(tǒng)前端頁面，這時候建立會話完成。

如何傳遞數(shù)據(jù)

既然是通過瀏覽器傳遞數(shù)據(jù)，有兩種方式，第一種是通過在Url上拼接參數(shù)，比如 www.baidu.com?userId=123 。

第二種是通過Cookie的形式傳遞，但是由于Cookie不能跨域，就導(dǎo)致了部分局限性。

為了體現(xiàn)對技術(shù)的追求，我偷偷的補充了一句：不過我發(fā)現(xiàn)在淘寶的Cookie中，能夠看到天貓的domain，好像是用Jsonp實現(xiàn)的。

安全性如何保證

不管是URL還是Cookie傳遞數(shù)據(jù)，如何保證數(shù)據(jù)的安全性呢？

保證數(shù)據(jù)的安全性總的來說有幾種實現(xiàn)：

1. 從軟件層面上進行保證，比如說可見性等。

2. 通過加密算法對數(shù)據(jù)進行加密。

因為從瀏覽器層面保證數(shù)據(jù)不可見不太現(xiàn)實，所以可以對數(shù)據(jù)進行加密，并且這個數(shù)據(jù)加解密的過程應(yīng)該由服務(wù)端來實現(xiàn)。

比如：用戶在 系統(tǒng)A 登錄后，系統(tǒng)A 的服務(wù)端通過某種加密算法以及某個秘鑰對用戶數(shù)據(jù)進行加密，接著返回給前端。系統(tǒng)A 頁面跳轉(zhuǎn)到系統(tǒng)B時帶上這個加密信息，接著調(diào)用系統(tǒng)B服務(wù)端接口進行登錄。系統(tǒng)B 通過解密數(shù)據(jù)獲取登錄者的用戶信息進行登錄即可。

單點登錄具體是如何實現(xiàn)

“重頭戲來了”，因為我們所有系統(tǒng)的頂級域名都是一樣的，因此不會存在跨域問題。為了降低接入成本，我們采用的是 Cookie加密 的形式。

比如用戶在 系統(tǒng)A 登錄后，系統(tǒng)A會往瀏覽器中寫入Cookie, Key 為userInfo，value值為用戶A的accountId。當然這個accountId是加密過的。

然后用戶在訪問系統(tǒng)B的頁面時，由于屬于同一個頂級域名，會帶上 Cookie。調(diào)用系統(tǒng)B接口時，判斷 Cookie中存在用戶信息，如果存在，通過Secret進行解密獲取用戶的accountId，隨后把用戶數(shù)據(jù)放到Session中，從而進行登錄。

這樣做還有一個好處就是：用戶可以直接在瀏覽器中輸入域名進行跳轉(zhuǎn)，而不是需要在 系統(tǒng)A 點擊跳轉(zhuǎn)到系統(tǒng)B。畢竟一般的用戶都是把鏈接保存在書簽的。

加密的Secret是怎么實現(xiàn)的

Secret采用的是系統(tǒng)約定的形式，這個值在系統(tǒng)中以加密的形式進行存儲，并且使用的配置中心，再加上我們系統(tǒng)使用的是專用網(wǎng)絡(luò)，基本不存在泄漏的風險。

使用Cookie 可能會存在被攻擊的風險，你知道哪些嗎

使用Cookie存儲的方式可能會受到Xss攻擊，也就是攻擊者在頁面上注入惡意腳本，然后在瀏覽器上運行這段腳本，從而獲取用戶的數(shù)據(jù)，比如Cookie等，危害數(shù)據(jù)安全。這有點像我們后端的SQL注入。

所以我們的系統(tǒng)在設(shè)置用戶Cookie時都會設(shè)置 HttpOnly=true，這樣通過js腳本將無法讀取到cookie信息，增強了使用Cookie的安全性。

另外除了Xss攻擊外，還會存在Csrf攻擊，也就是跨站請求偽造，攻擊者一般會誘導(dǎo)用戶進入第三方網(wǎng)站。然后在第三方網(wǎng)站中，通過比較吸引人的鏈接讓用戶點擊。從而冒充用戶對被攻擊的網(wǎng)站執(zhí)行某項操作的目的。

用戶登錄的時效性怎么保證

在單系統(tǒng)條件下，如果是標準的 Cookie-Session 機制，用戶登錄后調(diào)用接口，這個 Session 會進行續(xù)簽，從而讓會話保持下去。會話的生命周期變成了主要由服務(wù)端來保證

但是通過目前的這種形式，通過Cookie中是否存在用戶信息判斷是否登錄，會出現(xiàn)一個情況就是只要這個用戶信息也就是Cookie一直存在，那么用戶就永遠不會退出。（因為我們只會對數(shù)據(jù)進行解密，并且用戶在登錄后，Cookie并不會設(shè)置有效期），也就是說這個會話的生命周期變成了由 Cookie 來保證。

所以我們有兩種方案，一種是對 Cookie 添加過期時間，比如 30 分鐘，只要Cookie消失了，說明用戶登錄狀態(tài)失效。第二種是在userInfo這個Cookie的Value值中添加過期信息，然后每次接口調(diào)用時服務(wù)端判斷是否超時。

添加過期時間這種方案可行嗎

問題點在于續(xù)簽問題，這兩種方式不可避免的都需要刷新，也就是說用戶只要請求后端服務(wù)，都需要重新設(shè)置Cookie的過期時間或者修改Value的值。這個相對的就比較蠢了，而且還會有性能問題。

所以我們項目的目前方案是由Cookie來保證這個會話的生命周期，并且不進行續(xù)簽。