漫談單點登錄（SSO）(淘寶天貓)（轉載）

1. 摘要

（ 注意：請仔細看下摘要，留心此文是否是您的菜，若浪費寶貴時間，深感歉意！！！）

SSO這一概念由來已久，網絡上對應不同場景的成熟SSO解決方案比比皆是，從簡單到復雜，各式各樣應有盡有！開源的有OpenSSO、CAS ，微軟的AD SSO，及基于kerberos 的SSO等等……這些優秀的解決方案盡顯開發及使用者的逼格，當然需求所致無謂好壞高低，滿足實際之需才是王道！

本文并不討論上述提到的方案的整合使用、或者復雜場景如：安全、防火墻、N 多個系統層疊調用這種"巨型項目"里SSO的實現與使用，也并不涉及 C/S 、C/S+B/S 的SSO解決方案，僅關注B/S 上的SSO實現。雖是如此，然而萬變不離其宗，這里我們將從一個簡而小的登錄場景去接觸SSO的本質，描述如何原生態地自實現一個輕量、微核的SSO（本文不提供源碼）。

文章將由淺入深地探討SSO（單點登錄），涉及SSO的定義、表現、原理、實現細節等方面的闡述，借助大家熟知的淘寶、天貓登錄場景，通過對阿里登錄的模仿實現，建立一個簡單模型，然后不斷由該模型進行迭代并對每一個迭代版本進行詳細描述，最終得到一個支持跨域的SSO（ 力求條理清晰，層層遞進，簡單但有深度！！！！開始部分本著讓即使從未聽過SSO的同學也能夠從抽象文字定義的概念印象過渡到具象的視覺認知這一宏（zhuang）偉（bi）理念入手，將會有很多淺顯的描述，"老司機" 可以快速掠過）

?

2. SSO簡介

?

2.1 SSO定義

?

SSO（ Single Sign-On ），中文意即單點登錄，翻譯得比較精簡，個人覺得 Wiki 上的解釋更細膩點—— SSO, is a property of access control of multiple related, but independent software systems. With this property a user logs with a single ID and password to gain access to connected system or systems without using different usernames or passwords, or in some configurations seamlessly sign on at each system.?( 單點登錄是一種控制多個相關但彼此獨立的系統的訪問權限, 擁有這一權限的用戶可以使用單一的ID和密碼訪問某個或多個系統從而避免使用不同的用戶名或密碼，或者通過某種配置無縫地登錄每個系統?).??注：系統，在本文特指WEB 應用或者WEB 服務；用戶，下文也會稱之為User；ID，用戶標識；密碼，本文也稱其為口令，Password, Passcode 或者 Pin。

?

OK，從上面的定義中我們總結出 與?SSO 交互的2個元素：1.? 用戶，2. 系統，它的特點是：一次登錄，全部訪問。上面提到SSO是訪問控制的一種，控制用戶能否登錄，即驗證用戶身份，而且是所有其它系統的身份驗證都在它這里進行，那么我們是不是可以認為SSO還是一個驗證中心。那么從整個系統層面來看SSO，它的核心就是這3個元素了：1. 用戶，2. 系統，3. 驗證中心。可能扯了那么多還是不足以形象地描述我們萌萌的SSO，吶，有圖有真相：

?

?

既然SSO這么棒，應該如何實現呢？

?

?

2.2 SSO示例——淘寶、天貓的登錄場景

?

我們暫不考慮細節，先從SSO需要解決的問題入手：使用一個賬戶通過一次登錄，即可在多個相關的系統之間來回訪問，為了更加形像我們還是上圖：(多圖預警)

登錄頁面，網址：login.taobao.com ….. 我將在 login.taobao.com 所指的系統進行登錄

?

?

訪問網站，第一張網址：buyertrade.taobao.com…. 訪問 buyertrade.taobao.com所指的系統了；然后訪問另一張網頁網址為：favoriate.taobao.com，?訪問favoriate.taobao.com?所指系統，兩個系統的 Domain 是相同的，請注意這點；

?

? ???

?

?

接下來我再分別訪問淘寶(www.taobao.com)和天貓(www.tmall.com)的首頁 ，圖中顯示我仍舊是登錄的( 注意：這里是不同的Domain下，系統之間的來回訪問)

?

???????????????

?

可以看到，我除了在第一張網頁圖那里需要輸入用戶名（ID）和口令（password）進行登錄，再訪問其它相關系統時，從圖2-5 中所有的訪問操作，無論域名相同還是不同我都不需要再登錄了，它們都知道我叫"望向明天"！對，沒錯，這就是SSO的作用：一次登錄，全部訪問，讀者也可以嘗試下看看是不是如此；

?

3. SSO實現描述

好，經過我上面一大段廢話，基本上對SSO要解決什么問題有一個清晰的認識。現在我們自行腦（yi）補（yin）下SSO 的原理是什么樣的。

1. 一個賬戶：嗯，規定所有系統統一使用相同賬戶，就能保證一個賬戶了；
2. 一次登錄全部訪問：通過SSO登錄后，讓其告知其它各個系統保存該用戶的信息，用戶就不用重復多次的登錄了；

嗯，問題解決了，沒錯，就這樣。

?

3.1 方案1

由上面的猜想可以得到第1個解決方案，記為方案1。這里對這個猜想做一點小小的優化，猜想中第2點 "各個系統保存" 好讓人鬧心，同一份數據保存多份，太浪費，這里我們把每個已登錄的用戶信息保存到公共緩存中。好，我們再來描述下這個方案：

1. User 發送登錄請求給SSO，附上自己的 ID 和 password；
2. SSO驗證成功將用戶信息保存在公共緩存 Cache 中；
3. User每次發送請求給系統 Ai 時，將 ID 作為請求參數；
4. 系統 Aj 通過 請求中傳過來的 User ID從公共緩存 Cache 中驗證 User 是否登錄，完成后續動作；

?

文字完了，接下來看看方案1的架構圖和時序圖：

?

?

嗯，圖文并茂的樣子，難道就這么大功告成了？ 我們先把方案1中完成的第一版 SSO 記為SSO_V1，接下來我們來好好地捋一捋。

?

3.2 方案2

SSO_V1 貌似解決了問題，但是深入思考，細思極恐！因為這個設計有Bug：每次傳 ID 給服務Ai，但是這個ID 每次怎么獲取來呢？登錄SSO的時候，這倒沒有問題，可以讓用戶填！但第2次請求是發給Ai中的某一個 Aj 時，ID 要怎么來（ 假設百度和新浪是相關但彼此獨立的系統，登錄百度后，再訪問新浪時怎么讓新浪取到與登錄百度時一樣的ID吧）？總不至于每次發請求時都要求用戶填一遍ID 吧？

?

其實我們把 猜想 中最值得思考的問題之一忽略掉了：

如何讓SSO"告知"系統Ai，當前登錄的User 的ID和password？

?

這問題可以這樣來描述：假設有W (?www.weidai.com?)和 T( trade.weidai.com ) 兩個系統，W和T 都通過S (login.weidai.com) 系統登錄，當由U訪問W再轉向S 完成登錄后，怎樣做才能使 U 訪問T 時不需要再一次通過 S 進行登錄驗證？

?

對，如果你是WEB 開發的老司機，很自然你會想到用cookie?，即把用戶信息（ 本文也會稱之為UserInfo ）保存在cookie?當中，因為 無論W 、T 或者 S 它們的Domain是一樣的——都是 weidai.com ——同一Domain，這有何用？用處就在于 W 、T 以及 S 可以共享此路徑下的?cookie。這里，讓我們優化的心再一次燃燒起來——直接保存用戶的 ID 和 口令 對于我們這么有逼格，有追求的猿來說有點太不講究——為什么呢？不太安全，cookie?中 最好保存一個?公共Session ID（ 請和WEB 自己生成的Seesion ID進行區分 ）?，而我們的公共緩存 Cache 中保存的 UserInfo 是一個由?公共Session ID為Key?，以包含用戶標識和口令的數據結構為Value的Map。最后附上這一流程的時序圖及簡要說明：

?

?

1. U訪問W ，W進行驗證，驗證失敗，跳轉至SSO，要求U登錄；
2. U通過SSO登錄，SSO進行驗證，成功并生成SessionID，隨后將UserInfo（?SessionID、ID和口令）存儲到公共緩存C 中，跳轉至W（攜帶SessionID），并允許U訪問W；
3. U保存UserInfo （?SessionID?） 至?cookie?;（這里請將 U 看成一個瀏覽器，當下文有提到 U 保存XXX至Cookie時，讀者請自行切換）
4. U 再訪問 T ( 并攜帶 在3 中保存至cookie?中的 UserInfo ) ，T從公共緩存中拉取UserInfo 進行驗證，成功則允許訪問；

?

嗯，又是圖文并茂的樣子，難道再一次大功告成？ 我們暫時把剛才的方案記為方案2，并把方案2中完成的升級版SSO記為SSO_V2，接下來我們再來好好地捋一捋！

?

3.3 方案3

SSO_V2 能夠在 Domain 相同的情況下"完美"解決問題，但是在Domain不同的情況下怎么做到免登呢？如上面圖示淘寶（?www.taobao.com?）和天貓（?www.tmall.com?）若采用SSO_V2 肯定無法做到免登的，因為我們知道當訪問天貓時（Domain 為tmall.com ），淘寶（ Domain 為 taobao.com ）下的 cookie 是無法隨訪問請求一并傳給與天貓相關的系統的。所以問題變成，怎么讓不同Domain下的系統也"知曉"用戶已經登錄的實事？

?

在我們提出SSO_V3前，我們先看看SSO 本質是什么？通過這么多的文字描述、樣圖解釋，我們可以看到，要讓用戶"一次登錄，全部訪問"無非就是讓所有的系統共享"一份"（相同）已驗證的、安全可靠的驗證信息。所以問題就可以轉化為：不同Domain下的系統如何共享一份的驗證信息？既然Domain無法做到交叉訪問，那我們可以讓不同Domain下的WEB應用持有相同的驗證信息，這在效果上不就是一份嗎！所以最終要解決的問題就是：SSO系統如何使不同的 Domain 擁有一份相同的cookie？ —— 讓SSO在用戶進行登錄時再去訪問其它域下的系統，并讓各個系統保存一樣的驗證信息，這樣不同域下就會有同一份cookie。

?

以下是SSO_V3的時序圖和文字說明，這里我們假設 SSO 的Domain 為 SD，T 的 Domain 為 TD：

1. U第一次訪問W，W驗證失敗，跳轉至SSO要求U進行登錄驗證；
2. 登錄并使各不同Domain下：
   1. U 給SSO發送登錄請求，SSO驗證成功，生成SessionID 并保存UserInfo；
   2. 返回給U的Response 將 UserInfo 存放至cookie中，Domain為SD；
   3. 將 2 中 cookie 內容作為query parameter 重定向至T，T驗證后成功返回給U，也在Response 中設置 cookie；Domain為TD；
   4. U自動訪問SSO，SSO將請求重定向至W，完成U對W 的訪問；
3. U 再訪問 T，驗證成功并允許U進行訪問；

?

嗯，還是圖文并茂的樣子，這下是不是可以完事了呢？我們還是把剛才的方案記為方案3，并把方案3中完成的升級版SSO記為SSO_V3，然后還是來好好地捋一捋！

?

3.4 方案4

再細細的考慮下SSO_V3的實現方式，有沒有感覺它哪里有點不對勁（ 思維一直跟著我來走，是不是被繞暈了，想發現不對勁，怎么可能）？ SSO_V3 使不同 Domain 獲取相同的cookie 拷貝時，表面是在U處主動發出向Ｔ的請求（其實是被動）， 但實際上是 SSO 返回給 U 的頁面自動完成的（通過 JS、通過頁面自動跳轉、iframe都可以實現）。所以方案SSO_V3要求SSO 預先知道有哪些系統是跨域的！！！而且它還有一個很嚴重的問題：假如與SSO相關但相互獨立的系統中，有 20+ 需要跨域才能訪問，而SSO要在用戶登錄時完成20+跳轉……現在你是不是要呵呵了？貌似完美解決跨域的SSO_V3 竟然如此有問題，有沒有心好塞！

?

SSO_V3 解決的核心問題是：針對跨域的系統，各系統間如何保證獲取到的?驗證信息是一致的，解決方法即是在用戶第一次登錄時把驗證信息復制給所有跨域的系統。這種方案在跨域系統少的情況下倒是不需要有太多擔心，但是當跨域系統多、且驗證步驟比較復雜時用戶將會卡在登錄界面，最后不得不怒關頁面！所以當理清這些邏輯，很自然就會想到接下來要如何對SSO_V3進行優化。核心思想就是：既然一次性解決會有問題，那就分多次解決！簡單的描述下我們將要看到的SSO_V4，用戶登錄后，當第一次訪問跨域系統W 時，跳到SSO復制一份至W的cookie中，過程結束；當訪問T時，重復該處理動作。

?

以下為SSO_V4的時序圖及簡要說明：

?

1. 用戶U訪問W ，W進行驗證，驗證失敗，跳轉至SSO，要求U登錄；
2. U通過SSO登錄，SSO進行驗證，成功并生成SessionID，隨后將UserInfo（?SessionID、ID和口令）存儲到公共緩存C 中，跳轉至W（攜帶SessionID），并允許U訪問W；U保存UserInfo （?SessionID?） 至?cookie；
3. U訪問T，T 進行驗證，失敗跳轉至SSO，SSO將觸發U請求SSO將驗證信息隨請求一并發給SSO，經SSO驗證成功跳轉至Ｔ，允許U對T 的訪問；使U保存UserInfo（ SessionID）至cookie；

?

3.5 小結

其實我們通過上面的實用版（SSO_V2，SSO_V3，SSO_V4）SSO，可以看到除了用戶的第一次登錄某個應用相對來說比較特殊，其它處理都是一致的。所以當我們拋去細節之后，不仿這樣聯想SSO的實現：完成登錄邏輯并使各系統共享驗證信息和驗證邏輯，從這個層次去看SSO，我們發現它其實只負責用戶登錄和身份驗證這2、3個點。

?

下面是用戶第一次登錄及SSO與其它系統交互的簡圖：

?

?

4. 設計與實現

4.1 驗證信息的安全考慮

第3部分中的身份驗證和驗證信息方面都做得比較簡單，在實際項目中不可能如此使用！在此提出一個方案以供參考（這也是比較流行的一種）。

1. 使用 HTTPS 進行用戶登錄；
2. 為每個用戶生成一個對稱密鑰Ku；
3. 驗證信息由"ID"+ "password"+ SessionID 組成，當然你可以按需設置，比如再加個IP 地址……
4. 存儲在cookie 中的驗證信息，ID 和口令部分經由用戶密鑰Ku和SSO公鑰處理后在存放至"客戶端"；

這樣處理后相信能夠滿足大部分應用的需求了！

?

4.2 SSO的概要設計

4.2.1 整體思路

SSO這一理念到目前為止已經非常成熟，關于它的各種設計、設置都可以定制一套標準了。然而由于SSO與用戶有強關聯，所以很多設計在最初時往往會把SSO設計成一個用戶管理系統，而使得SSO與業務耦合，隨著業務的不斷變化和演進，底層數據結構、接口不斷的復雜化，又反過來使得上層服務的架構設計變得尷尬。

若做更進一層的抽象和劃分，SSO只需負責登錄這單一功能即可，設計上滿足單一職責原則[1]，加上幾乎所有網站的登錄都大同小異(可能登錄界面會變幻無常)且不與業務有過多牽連，這又使得SSO與業務完全分離，無論將來業務怎樣演進，產品如何迭代，SSO作為底層應用可以以不變應萬變。Really? All problem in computer science can be solved with another level of indirection，except of course for the problem of too many indirections.[2]??如何在設計中做到復雜與簡潔的平衡，需要根據實際情境深度地考量，這可以扯出長篇大論了（按下不表），我們的SSO姑且就搞這幾個功能：登錄、記錄軌跡、登出，以下是用例圖：

?

第3節第5部分有提到"登錄交由SSO完成，各系統共享一套驗證邏輯"，很自然的驗證這一邏輯對SSO也是必須的，在此就由SSO來完成，其它系統只需將其配置到各自系統里即可。再加上SSO是用戶"做案的第一現場"，所以記錄用戶登錄信息的事也很自然的就讓SSO給干起來了，而且這一功能不僅能夠讓用戶感受到我們對客戶的用心，同時也為后期數據分析業務提供數據源！

?

4.2.2 數據表設計

經過上面的討論，我們著手思考SSO的數據結構——數據表設計（個人認為面向對象編程中數據結構的優劣基本決定整個應用的質量）。從SSO 功能簡單及其微服務的定位，SSO的表應該簡潔、單一，上層服務若需要對其進行擴展，只需要對基本表進行外鍵引用即可！這里我們暫時只用3張表，分別為User、Trace（用戶軌跡表）和使用平臺表，圖示與描述如下：

?

?

用戶表：User

1. uid 用戶唯一標識，（ varchar 是否有更好）
2. name ：賬號，可以唯一標識用戶，email，phone等都唯一標識用戶；
3. status：用戶狀態；（凍結，已刪除……）；
4. key ：用戶密鑰；
5. info：擴展字段，用以應變需求；

?

用戶軌跡表：Trace

1. type ：軌跡類型，（刪除，登錄，登出，修改……）；
2. time ：操作時間；
3. info同上，uid 用戶表外鍵，pid 為Platform的外鍵；

?

使用平臺表：Platform

1. ip：用戶登錄ip
2. address：用戶登錄地址，可由IP 解析得到，（手機端可以使用GPS）；
3. platform：使用平臺的信息，將在請求的head上得到；
4. info同上，tid 表示Trace 表的外鍵；

?

4.2.3 簡要類設計

通過上面的整體思路及數據結構的定型，我們可以繼續鋪開將SSO要涉及到的一些主體類及主要方法定義好，仍舊上圖：

?

寫到這里，對于這個圖示就不再做過多解釋，大家基本可以開始做各種各樣的腦補了！額，僅說小小的一個點：驗證由Interceptor實現，這樣驗證邏輯則可以以插件形式配置到其它系統，實現所有系統共享一套驗證邏輯，當然你也可以根據具體情況做成Filter，看個人愛好; 訪問這方面交給第三方處理，比如由Shiro、Spring Security等來完成……醬紫，結束！