單點登入是我比較喜歡的乙個技術解決方案，一方面他能夠提高產品使用的便利性，另一方面他分離了各個應用都需要的登入服務，對效能以及工作量都有好處。自從上次研究過jwt如何應用於會話管理，加之以前的專案中也一直在使用cas這個比較流行的單點登入框架，所以就一直在琢磨如何能夠把jwt跟單點登入結合起來一起使用，盡量能把兩種技術的優勢都整合到專案中來。本文介紹我從cas思考得出的sso的實現方案。
本文主要是通過時序圖的方式來介紹jwt sso的實現原理，具體的技術實現暫時還沒有，不過當你理解了這個方案的原理後，你會覺得最終的實現並不會特別複雜，你可以用任意的平台語言來實現它。下面的時序圖，模擬了三個服務，分別是cas、系統a、系統b，它們分別部署在cas.com，systema.com和systemb.com；cas這個服務用來管理sso的會話；系統a和系統b代表著實際的業務系統。我從五個場景分別來說明這個sso方案的實現細節。下面先來看第乙個。
場景一：使用者發起對業務系統的第一次訪問，假設他第一次訪問的是系統a的some/page這個頁面，它最終成功訪問到這個頁面的過程是：
它用到了兩個cookie(jwt和sid)和三次重定向來完成會話的建立和會話的傳遞；
jwt的cookie是寫在systema.com這個域下的，所以每次重定向到systema.com的時候，jwt這個cookie只要有就會帶過去
sid的cookie是寫在cas.com這個域下的，所以每次重定向到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的單點登入實現過程：
使用者登入 單點登入
首先是為啥要用單點登入的問題，單點登入也就是sso sso是在多個應用系統中，使用者只需要登入一次就可以訪問所有相互信任的應用系統。1 任何系統都必須去登陸伺服器進行登入 2 伺服器就記住了登入狀態 3 其他系統訪問受保護資源，需要再次登入，跳轉到sso server登入的時候，伺服器告訴客戶端，已...
單點登入簡介
單點登入 跨平台 跨應用的身份驗證解決方案 single sign on 簡稱為 sso 一 什麼是單點登入 single sign on 單點登入 single sign on 簡稱為 sso，是目前比較流行的企業業務整合的解決方案 sso的定義是在多個應用系統中，使用者只需要登入一次就可以訪問所...
單點登入原理
單點登入sso single sign on 說得簡單點就是在乙個多系統共存的環境下，使用者在一處登入後，就不用在其他系統中登入，也就是使用者的一次登入能得到其他所有系統的信任。單點登入在大型 裡使用得非常頻繁，例如像阿里巴巴這樣的 在 的背後是成百上千的子系統，使用者一次操作或交易可能涉及到幾十個...