單點登錄是我比較喜歡的一個技術解決方案，一方面他能夠提高產品使用的便利性，另一方面他分離了各個應用都需要的登錄服務，對性能以及工作量都有好處。自從上次研究過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的單點登錄實現過程：
https://apereo.github.io/cas/4.1.x/protocol/CAS-Protocol.html
它的流程跟我這個差別不是特別大，但是從清晰層面來說，我寫的還是要更明瞭一些，所以對比起來閱讀，可能理解會更透徹些。