點擊上方“Java知音”，選擇“置頂公眾號”

技術文章第一時間送達！

作者：流云諸葛http://cnblogs.com/lyzg/p/6132801.html

推薦閱讀(點擊即可跳轉閱讀)

1. 淘寶服務端高并發分布式架構演進之路

2. IntelliJ IDEA 從入門到上癮教程，2019圖文版！

3. 高并發場景下緩存處理的一些思路

4. 權限設計的一些想法和思考

單點登錄是我比較喜歡的一個技術解決方案，一方面他能夠提高產品使用的便利性，另一方面他分離了各個應用都需要的登錄服務，對性能以及工作量都有好處。

自從上次研究過JWT如何應用于會話管理，加之以前的項目中也一直在使用CAS這個比較流行的單點登錄框架，所以就一直在琢磨如何能夠把JWT跟單點登錄結合起來一起使用，盡量能把兩種技術的優勢都集成到項目中來。本文介紹我從CAS思考得出的SSO的實現方案。

前言

其實CAS這個方案很好，非常強大，它最新的版本已經集成JWT了，所以要是不想自己開發單點登錄的服務的話，完全可以考慮使用CAS。但是我認為，我們在做項目的時候，也許一開始并不需要這么強大的產品，CAS提供的登錄形式有很多，而我們只需要應用其中的一種；

而且它這個框架正是因為強大，所以也會比較復雜，簡單上手容易，但是遇到一些特殊的需求，比如我們想在CAS里面加入微信登錄，那就需要對它的原理以及API有比較深入的了解才行。綜合考慮，還是弄清楚CAS的原理，自己來實現一個基本的SSO服務比較放心。

本文的內容需要對JWT和SSO有一個基本的了解，你可以從這兩篇文章來了解JWT的用途：

http://www.cnblogs.com/lyzg/p/6067766.htmlhttp://www.cnblogs.com/lyzg/p/6028341.html

還可以從下面的資料來了解SSO的內容：

https://baike.baidu.com/item/SSO/3451380?fr=aladdin

方案介紹

本文主要是通過時序圖的方式來介紹JWT SSO的實現原理，具體的技術實現暫時還沒有，不過當你理解了這個方案的原理后，你會覺得最終的實現并不會特別復雜，你可以用任意的平臺語言來實現它。

下面的時序圖，模擬了三個服務，分別是CAS、系統A、系統B，它們分別部署在http://cas.com，http://systemA.com和http://systemB.com；CAS這個服務用來管理SSO的會話；系統A和系統B代表著實際的業務系統。我從五個場景分別來說明這個SSO方案的實現細節。下面先來看第一個。

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

圖片點擊放大看，下同

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

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

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

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

在驗證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登錄頁進行處理。

方案總結

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

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

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

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

使用https

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

管理好密鑰

防范CSRF攻擊。

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

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

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

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

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

假如是自己來實現，那么可以輕易的在CAS里面集成用戶注冊服務以及第三方登錄服務，如微信登錄等。

它的缺陷是：

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

登錄后的后續請求，每次都需要跟CAS進行會話驗證，所以CAS的性能負載會比較大

登陸后的后續請求，每次都跟CAS交互，也會增加請求響應時間，影響用戶體驗。

本文小結

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

https://apereo.github.io/cas/4.1.x/protocol/CAS-Protocol.html

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

另外，這個方案考慮地不一定很全面，所以要是您發現了其中的問題，還請您幫忙指正，非常感謝。

總結

以上是生活随笔為你收集整理的cas 登录之后不跳转_图解JWT如何用于单点登录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。