對SSO單點登陸和OAuth2.0的區別和理解

SSO是Single Sign On的縮寫，OAuth是Open Authority的縮寫，這二者都是使用令牌的方式來代替用戶密碼訪問應用。流程上來講他們很是類似，但概念上又十分不一樣。

• SSO你們應該比較熟悉，它將登陸認證和業務系統分離，使用獨立的登陸中心，實現了在登陸中心登陸後，全部相關的業務系統都能免登陸訪問資源。
• OAuth2.0原理可能比較陌生，但平時用的卻不少，好比訪問某網站想留言又不想註冊時使用了微信受權。

以上二者，你在業務系統中都沒有帳號和密碼，帳號密碼是存放在登陸中心或微信服務器中的，這就是所謂的使用令牌代替帳號密碼訪問應用。

SSO

二者有不少類似之處，下面咱們來解釋一下這個過程。先來說解SSO，經過SSO對比OAuth2.0，才比較好理解OAuth2.0的原理。SSO的實現有不少框架，好比CAS框架，如下是CAS框架的官方流程圖。

上面的流程大概爲：

• 用戶輸入網址進入業務系統Protected App，系統發現用戶未登陸，將用戶重定向到單點登陸系統CAS Server，並帶上自身地址service參數
• 用戶瀏覽器重定向到單點登陸系統，系統檢查該用戶是否登陸，這是SSO(這裏是CAS)系統的第一個接口，該接口若是用戶未登陸，則將用戶重定向到登陸界面，若是已登陸，則設置全局session，並重定向到業務系統
• 用戶填寫密碼後提交登陸，注意此時的登陸界面是SSO系統提供的，只有SSO系統保存了用戶的密碼，
• SSO系統驗證密碼是否正確，若正確則重定向到業務系統，並帶上SSO系統的簽發的ticket
• 瀏覽器重定向到業務系統的登陸接口，這個登陸接口是不須要密碼的，而是帶上SSO的ticket，業務系統拿着ticket請求SSO系統，獲取用戶信息。並設置局部session，表示登陸成功返回給瀏覽器sessionId(tomcat中叫JSESSIONID)
• 以後全部的交互用sessionId與業務系統交互便可

OAuth2.0

OAuth2.0有多種模式，這裏講的是OAuth2.0受權碼模式，OAuth2.0的流程跟SSO差很少

• 用戶在某網站上點擊使用微信受權，這裏的某網站就相似業務系統，微信受權服務器就相似單點登陸系統
• 以後微信受權服務器返回一個確認受權頁面，相似登陸界面，這個頁面固然是微信的而不是業務系統的
• 用戶確認受權，相似填寫了帳號和密碼，提交後微信鑑權並返回一個ticket，並重定向業務系統。
• 業務系統帶上ticket訪問微信服務器，微信服務器返回正式的token，業務系統就可使用token獲取用戶信息了

以上，就是個人SSO和OAuth2.0的理解

參考資料

• CAS單點登陸原理解析