單點登陸（SSO）的設計&實現思路

1、前言

一、SSO說明

SSO英文全稱Single Sign On，單點登陸。SSO是在多個應用系統中，用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。https://baike.baidu.com/item/...

例如訪問在網易帳號中心（http://reg.163.com/ ）登陸以後
訪問如下站點都是登陸狀態

• 網易直播 http://v.163.com
• 網易博客 http://blog.163.com
• 網易花田 http://love.163.com
• 網易考拉 https://www.kaola.com
• 網易Lofter http://www.lofter.com

二、設計目標

本篇文章也主要是爲了探討如何設計&實現一個SSO系統

如下爲須要實現的核心功能：

• 單點登陸
• 單點登出
• 支持跨域單點登陸
• 支持跨域單點登出

2、SSO設計與實現

一、核心應用與依賴

應用/模塊/對象	說明
前臺站點	須要登陸的站點
SSO站點-登陸	提供登陸的頁面
SSO站點-登出	提供註銷登陸的入口
SSO服務-登陸	提供登陸服務
SSO服務-登陸狀態	提供登陸狀態校驗/登陸信息查詢的服務
SSO服務-登出	提供用戶註銷登陸的服務
數據庫	存儲用戶帳戶信息
緩存	存儲用戶的登陸信息，一般使用Redis

二、用戶登陸狀態的存儲與校驗

常見的Web框架對於Session的實現都是生成一個SessionId存儲在瀏覽器Cookie中。而後將Session內容存儲在服務器端內存中，這個 ken.io 在以前Session工做原理中也提到過。總體也是借鑑這個思路。
用戶登陸成功以後，生成AuthToken交給客戶端保存。若是是瀏覽器，就保存在Cookie中。若是是手機App就保存在App本地緩存中。本篇主要探討基於Web站點的SSO。
用戶在瀏覽須要登陸的頁面時，客戶端將AuthToken提交給SSO服務校驗登陸狀態/獲取用戶登陸信息

對於登陸信息的存儲，建議採用Redis，使用Redis集羣來存儲登陸信息，既能夠保證高可用，又能夠線性擴充。同時也可讓SSO服務知足負載均衡/可伸縮的需求。

對象	說明
AuthToken	直接使用UUID/GUID便可，若是有驗證AuthToken合法性需求，能夠將UserName+時間戳加密生成，服務端解密以後驗證合法性
登陸信息	一般是將UserId，UserName緩存起來

三、用戶登陸/登陸校驗

• 登陸時序圖

按照上圖，用戶登陸後Authtoken保存在Cookie中。 domian= test. com
瀏覽器會將domain設置成 .test.com，
這樣訪問全部*.test.com的web站點，都會將Authtoken攜帶到服務器端。
而後經過SSO服務，完成對用戶狀態的校驗/用戶登陸信息的獲取

• 登陸信息獲取/登陸狀態校驗

四、用戶登出

用戶登出時要作的事情很簡單：

1. 服務端清除緩存（Redis）中的登陸狀態
2. 客戶端清除存儲的AuthToken

• 登出時序圖

五、跨域登陸、登出

前面提到過，核心思路是客戶端存儲AuthToken，服務器端經過Redis存儲登陸信息。因爲客戶端是將AuthToken存儲在Cookie中的。因此跨域要解決的問題，就是如何解決Cookie的跨域讀寫問題。

解決跨域的核心思路就是：

• 登陸完成以後經過回調的方式，將AuthToken傳遞給主域名以外的站點，該站點自行將AuthToken保存在當前域下的Cookie中。
• 登出完成以後經過回調的方式，調用非主域名站點的登出頁面，完成設置Cookie中的AuthToken過時的操做。
• 跨域登陸（主域名已登陸）

• 跨域登陸（主域名未登陸）

• 跨域登出

3、備註

• 關於方案

此次設計方案更可能是提供實現思路。若是涉及到APP用戶登陸等狀況，在訪問SSO服務時，增長對APP的簽名驗證就行了。固然，若是有無線網關，驗證簽名不是問題。

• 關於時序圖

時序圖中並無包含全部場景，ken.io只列舉了核心/主要場景，另外對於一些不影響理解思路的消息能省就省了。

• 前置知識

一、Session的工做原理和使用經驗：https://ken.io/note/session-p...
二、Cookie的特色和使用經驗/建議總結：https://ken.io/note/cookie-fe...

以上，若有疑問，歡迎聯繫我：https://ken.io/home/about

---

本文首發於個人獨立博客：https://ken.io/note/sso-desig...