單點登入是我比較喜歡的一個技術解決方案，一方面他能夠提高產品使用的便利性，另一方面他分離了各個應用都需要的登入服務，對效能以及工作量都有好處。自從上次研究過JWT如何應用於會話管理，加之以前的專案中也一直在使用CAS這個比較流行的單點登入框架，所以就一直在琢磨如何能夠把JWT跟單點登入結合起來一起使用，儘量能把兩種技術的優勢都整合到專案中來。本文介紹我從CAS思考得出的SSO的實現方案。

前言

其實CAS這個方案很好，非常強大，它最新的版本已經整合JWT了，所以要是不想自己開發單點登入的服務的話，完全可以考慮使用CAS。但是我認為，我們在做專案的時候，也許一開始並不需要這麼強大的產品，CAS提供的登入形式有很多，而我們只需要應用其中的一種；而且它這個框架正是因為強大，所以也會比較複雜，簡單上手容易，但是遇到一些特殊的需求，比如我們想在CAS裡面加入微信登入，那就需要對它的原理以及API有比較深入的瞭解才行。綜合考慮，還是弄清楚CAS的原理，自己來實現一個基本的SSO服務比較放心。

本文的內容需要對JWT和SSO有一個基本的瞭解，你可以從這兩篇文章來了解JWT的用途：3種web會話管理的方式JWT實現token-based會話管理，還可以從下面的資料來了解SSO的內容：SSO_百度百科。

方案介紹

本文主要是通過時序圖的方式來介紹JWT SSO的實現原理，具體的技術實現暫時還沒有，不過當你理解了這個方案的原理後，你會覺得最終的實現並不會特別複雜，你可以用任意的平臺語言來實現它。下面的時序圖，模擬了三個服務，分別是CAS、系統A、系統B，它們分別部署在cas.com，systemA.com和systemB.com；CAS這個服務用來管理SSO的會話；系統A和系統B代表著實際的業務系統。我從五個場景分別來說明這個SSO方案的實現細節。下面先來看第一個。

場景一：使用者發起對業務系統的第一次訪問，假設他第一次訪問的是系統A的some/page這個頁面，它最終成功訪問到這個頁面的過程是：

在這個過程裡面，我認為理解的關鍵點在於：

1. 它用到了兩個cookie(jwt和sid)和三次重定向來完成會話的建立和會話的傳遞；

1. jwt的cookie是寫在systemA.com這個域下的，所以每次重定向到systemA.com的時候，jwt這個cookie只要有就會帶過去；

2. sid的cookie是寫在cas.com這個域下的，所以每次重定向到cas.com的時候，sid這個cookie只要有就會帶過去；

3. 在驗證jwt的時候，如何知道當前使用者已經建立了sso的會話？因為jwt的payload裡面儲存了之前建立的sso 會話的session id，所以當cas拿到jwt，就相當於拿到了session id，然後用這個session id去判斷有沒有的對應的session物件即可。

還要注意的是：CAS服務裡面的session屬於服務端建立的物件，所以要考慮session id唯一性以及session共享（假如CAS採用叢集部署的話）的問題。session id的唯一性可以通過使用者名稱密碼加隨機數然後用hash演算法如md5簡單處理；session共享，可以用memcached或者redis這種專門的支援叢集部署的快取伺服器管理session來處理。

由於服務端session具有生命週期的特點，到期需自動銷燬，所以不要自己去寫session的管理，免得引發其它問題，到github裡找開源的快取管理中介軟體來處理即可。儲存session物件的時候，只要用session id作為key，session物件本身作為value，存入快取即可。session物件裡面除了session id，還可以存放登入之後獲取的使用者資訊等業務資料，方便業務系統呼叫的時候，從session裡面返回會話資料。

場景二：使用者登入之後，繼續訪問系統A的其它頁面，如some/page2，它的處理過程是：

從這一步可以看出，即使登入之後，也要每次跟CAS校驗jwt的有效性以及會話的有效性，其實jwt的有效性也可以放在業務系統裡面處理的，但是會話的有效性就必須到CAS那邊才能完成了。當CAS拿到jwt裡面的session id之後，就能到session 快取伺服器裡面去驗證該session id對應的session物件是否存在，不存在，就說明會話已經銷燬了（退出）。

場景三：使用者登入了系統A之後，再去訪問其他系統如系統B的資源，比如系統B的some/page，它最終能訪問到系統B的some/page的流程是：

這個過程的關鍵在於第一次重定向的時候，它會把sid這個cookie帶回給CAS伺服器，所以CAS伺服器能夠判斷出會話是否已經建立，如果已經建立就跳過登入頁的邏輯。

場景四：使用者繼續訪問系統B的其它資源，如系統B的some/page2：

這個場景的邏輯跟場景二完全一致。

場景五：退出登入，假如它從系統B發起退出，最終的流程是：

最重要的是要清除sid的cookie，jwt的cookie可能業務系統都有建立，所以不可能在退出的時候還挨個去清除那些系統的cookie，只要sid一清除，那麼即使那些jwt的cookie在下次訪問的時候還會被傳遞到業務系統的服務端，由於jwt裡面的sid已經無效，所以最後還是會被重定向到CAS登入頁進行處理。

方案總結

以上方案兩個關鍵的前提：

1. 整個會話管理其實還是基於服務端的session來做的，只不過這個session只存在於CAS服務裡面；

2. CAS之所以信任業務系統的jwt，是因為這個jwt是CAS簽發的，理論上只要認證通過，就可以認為這個jwt是合法的。

jwt本身是不可偽造，不可篡改的，但是不代表非法使用者冒充正常用法發起請求，所以常規的幾個安全策略在實際專案中都應該使用：

1. 使用https

2. 使用http-only的cookie，針對sid和jwt

3. 管理好金鑰

4. 防範CSRF攻擊。

尤其是CSRF攻擊形式，很多都是鑽程式碼的漏洞發生的，所以一旦出現CSRF漏洞，並且被人利用，那麼別人就能用獲得的jwt，冒充正常使用者訪問所有業務系統，這個安全問題的後果還是很嚴重的。考慮到這一點，為了在即使有漏洞的情況將損害減至最小，可以在jwt裡面加入一個系統標識，新增一個驗證，只有傳過來的jwt內的系統標識與發起jwt驗證請求的服務一致的情況下，才允許驗證通過。這樣的話，一個非法使用者拿到某個系統的jwt，就不能用來訪問其它業務系統了。

在業務系統跟CAS發起attach/validate請求的時候，也可以在CAS端做些處理，因為這個請求，在一次SSO過程中，一個系統只應該發一次，所以只要之前已經給這個系統簽發過jwt了，那麼後續 同一系統的attach/validate請求都可以忽略掉。

總的來說，這個方案的好處有：

1. 完全分散式，跨平臺，CAS以及業務系統均可採用不同的語言來開發；

2. 業務系統如系統A和系統B，可實現服務端無狀態

3. 假如是自己來實現，那麼可以輕易的在CAS裡面整合使用者註冊服務以及第三方登入服務，如微信登入等。

它的缺陷是：

1. 第一次登入某個系統，需要三次重定向（不過可以優化成兩次）；

2. 登入後的後續請求，每次都需要跟CAS進行會話驗證，所以CAS的效能負載會比較大

3. 登陸後的後續請求，每次都跟CAS互動，也會增加請求響應時間，影響使用者體驗。

本文小結

本文從理論層面介紹了結合jwt來實現SSO的方案原理，希望它能幫助一些朋友更好的理解SSO以及它的實現方法。本文方案參考自CAS的實現流程，你可以從下面這個資料瞭解CAS的單點登入實現過程：

它的流程跟我這個差別不是特別大，但是從清晰層面來說，我寫的還是要更明瞭一些，所以對比起來閱讀，可能理解會更透徹些。