單點登錄與權限管理本質：單點登錄介紹
阿新 • • 發佈：2018-04-23
單點登錄繼續介紹「單點登錄與權限管理」系列的第一部分：單點登錄與權限管理本質，前兩篇介紹了session與cookie 和 HTTP重定向 ，有了他們，瀏覽器就可以在多個系統間自動交互，實現自動登錄。
本篇介紹下單點登錄，所謂單點登錄，就是說用戶只需在一個地方登錄，訪問其他相關系統時，不需要重復登錄，隱式地自動登錄，這樣體驗會比較好。
主要從以下幾個方面介紹：
- 一個常見的交互流程
- 常見單點登錄協議
- 關鍵問題總結
一個常見的交互流程
我們項目中，使用CAS協議實現單點登錄，下面就以項目中的實現為例，先來看下其交互流程，對其實現有個基本的了解。
有2個系統，系統A是「客服工作臺」，主要給客服使用，可實時與來訪用戶及時聊天，解答用戶的問題。系統B是「工單系統」，對於不能解答的問題，客服會創建一個工單，更高級別或相關度高的人會看到工單進行處理。
客服希望在登錄系統A後，不需要手動登錄系統B，需要一個「單點登錄服務」，提供一個統一的登錄驗證，協調系統A、系統B的自動登錄，定義該服務為服務S，其CAS協議的場景的流程如下：
花了不少時間畫上面的圖，看著比較復雜，其實還好，希望大家花時間看下，如果前兩篇文章真正理解了，這塊就相對簡單了。
重點總結下該流程：
- 黑圓圈紅字，標識cookie的生成和使用，ABCDE表示5個cookie，1表示生成，2表示使用；
- 無論是系統A，還是系統B，如果沒有jessionid cookie，都會跳轉到服務S，如果攜帶了cookie1（登錄成功後生成的cookie），不需要登錄，會自動登錄，如果沒有攜帶cookie1，會跳轉到登錄頁面，登錄成功後會設置cookie1。
- cookie1是保持瀏覽器和服務S的，表示用戶已經登錄過了；
- cookie2、cookie4都是臨時cookie，主要是將服務碼帶到系統A或系統B，拿到服務碼後，通過後端請求服務S進行驗證，驗證過後，臨時cookie就失效了，主要是為了安全考慮。
- cookie3、cookie5和我們正常登錄產生的jessionid一樣，是各個子系統獨有的cookie；
如果還有疑問，可在下面留言，我會第一時間回復。
常見單點登錄協議
上面介紹的是CAS協議的一種，還有其他協議可實現單點登錄，比如CAS官網列舉的協議：
這些協議有不同的適用場景，比如好多網站都支持使用QQ、微信、微博直接登錄，只要你的QQ、微信、微博登錄者，就不用重復登錄，使用OAuth協議可比較好的實現這種場景。
後面會單獨介紹這些協議。
關鍵問題總結
無論是哪一種協議，都需要一個中間系統，對驗證和授權進行統一管理。另外，cookie的管理和安全問題需要重點考慮。
後面一篇會介紹下可能存在哪些安全問題，而對於安全問題如何解決，cookie和session具體如何管理，會在介紹每個具體協議的時候重點說明。
單點登錄與權限管理本質：單點登錄介紹