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的理解