一、概述

SSO是Single Sign On的縮寫，OAuth是Open Authority的縮寫，這兩者都是使用令牌的方式來代替用戶密碼訪問應(yīng)用。流程上來說他們非常相似，但概念上又十分不同。SSO大家應(yīng)該比較熟悉，它將登錄認證和業(yè)務(wù)系統(tǒng)分離，使用獨立的登錄中心，實現(xiàn)了在登錄中心登錄后，所有相關(guān)的業(yè)務(wù)系統(tǒng)都能免登錄訪問資源。

OAuth2.0原理可能比較陌生，但平時用的卻很多，比如訪問某網(wǎng)站想留言又不想注冊時使用了微信授權(quán)。以上兩者，你在業(yè)務(wù)系統(tǒng)中都沒有賬號和密碼，賬號密碼是存放在登錄中心或微信服務(wù)器中的，這就是所謂的使用令牌代替賬號密碼訪問應(yīng)用。

二、SSO

兩者有很多相似之處，下面我們來解釋一下這個過程。先來講解SSO，通過SSO對比OAuth2.0，才比較好理解OAuth2.0的原理。SSO的實現(xiàn)有很多框架，比如CAS框架，以下是CAS框架的官方流程圖。特別注意：SSO是一種思想，而CAS只是實現(xiàn)這種思想的一種框架而已

上面的流程大概為：

用戶輸入網(wǎng)址進入業(yè)務(wù)系統(tǒng)Protected App，系統(tǒng)發(fā)現(xiàn)用戶未登錄，將用戶重定向到單點登錄系統(tǒng)CAS Server，并帶上自身地址service參數(shù)

用戶瀏覽器重定向到單點登錄系統(tǒng)，系統(tǒng)檢查該用戶是否登錄，這是SSO(這里是CAS)系統(tǒng)的第一個接口，該接口如果用戶未登錄，則將用戶重定向到登錄界面，如果已登錄，則設(shè)置全局session，并重定向到業(yè)務(wù)系統(tǒng)

用戶填寫密碼后提交登錄，注意此時的登錄界面是SSO系統(tǒng)提供的，只有SSO系統(tǒng)保存了用戶的密碼，

SSO系統(tǒng)驗證密碼是否正確，若正確則重定向到業(yè)務(wù)系統(tǒng)，并帶上SSO系統(tǒng)的簽發(fā)的ticket

瀏覽器重定向到業(yè)務(wù)系統(tǒng)的登錄接口，這個登錄接口是不需要密碼的，而是帶上SSO的ticket，業(yè)務(wù)系統(tǒng)拿著ticket請求SSO系統(tǒng)，獲取用戶信息。并設(shè)置局部session，表示登錄成功返回給瀏覽器sessionId(tomcat中叫JSESSIONID)

之后所有的交互用sessionId與業(yè)務(wù)系統(tǒng)交互即可

最常見的例子是，我們打開淘寶APP，首頁就會有天貓、聚劃算等服務(wù)的鏈接，當你點擊以后就直接跳過去了，并沒有讓你再登錄一次

三、OAuth2.0

OAuth2.0有多種模式，這里講的是OAuth2.0授權(quán)碼模式，OAuth2.0的流程跟SSO差不多，在OAuth2中，有授權(quán)服務(wù)器、資源服務(wù)器、客戶端這樣幾個角色，當我們用它來實現(xiàn)SSO的時候是不需要資源服務(wù)器這個角色的，有授權(quán)服務(wù)器和客戶端就夠了。

授權(quán)服務(wù)器當然是用來做認證的，客戶端就是各個應(yīng)用系統(tǒng)，我們只需要登錄成功后拿到用戶信息以及用戶所擁有的權(quán)限即可

用戶在某網(wǎng)站上點擊使用微信授權(quán)，這里的某網(wǎng)站就類似業(yè)務(wù)系統(tǒng)，微信授權(quán)服務(wù)器就類似單點登錄系統(tǒng)

之后微信授權(quán)服務(wù)器返回一個確認授權(quán)頁面，類似登錄界面，這個頁面當然是微信的而不是業(yè)務(wù)系統(tǒng)的

用戶確認授權(quán)，類似填寫了賬號和密碼，提交后微信鑒權(quán)并返回一個ticket，并重定向業(yè)務(wù)系統(tǒng)。

業(yè)務(wù)系統(tǒng)帶上ticket訪問微信服務(wù)器，微信服務(wù)器返回正式的token，業(yè)務(wù)系統(tǒng)就可以使用token獲取用戶信息了

簡介一下OAuth2.0的四種模式：

授權(quán)碼（authorization-code）

授權(quán)碼（authorization code）方式，指的是第三方應(yīng)用先申請一個授權(quán)碼，然后再用該碼獲取令牌。這種方式是最常用的流程，安全性也最高，它適用于那些有后端的 Web 應(yīng)用。授權(quán)碼通過前端傳送，令牌則是儲存在后端，而且所有與資源服務(wù)器的通信都在后端完成。這樣的前后端分離，可以避免令牌泄漏。

隱藏式（implicit）

有些 Web 應(yīng)用是純前端應(yīng)用，沒有后端。這時就不能用上面的方式了，必須將令牌儲存在前端。RFC 6749 就規(guī)定了第二種方式，允許直接向前端頒發(fā)令牌。這種方式?jīng)]有授權(quán)碼這個中間步驟，所以稱為（授權(quán)碼）“隱藏式”（implicit）

密碼式（password）

如果你高度信任某個應(yīng)用，RFC 6749 也允許用戶把用戶名和密碼，直接告訴該應(yīng)用。該應(yīng)用就使用你的密碼，申請令牌，這種方式稱為"密碼式"（password）。

客戶端憑證（client credentials）

最后一種方式是憑證式（client credentials），適用于沒有前端的命令行應(yīng)用，即在命令行下請求令牌。

簡單流程

四、說一下幾個名詞的區(qū)別

首先，SSO是一種思想，或者說是一種解決方案，是抽象的，我們要做的就是按照它的這種思想去實現(xiàn)它

其次，OAuth2是用來允許用戶授權(quán)第三方應(yīng)用訪問他在另一個服務(wù)器上的資源的一種協(xié)議，它不是用來做單點登錄的，但我們可以利用它來實現(xiàn)單點登錄。在本例實現(xiàn)SSO的過程中，受保護的資源就是用戶的信息（包括，用戶的基本信息，以及用戶所具有的權(quán)限），而我們想要訪問這這一資源就需要用戶登錄并授權(quán)，OAuth2服務(wù)端負責(zé)令牌的發(fā)放等操作，這令牌的生成我們采用JWT，也就是說JWT是用來承載用戶的Access_Token的

最后，Spring Security、Shiro是用于安全訪問的，用來做訪問權(quán)限控制，都是一個用Java寫的框架

審核編輯 ：李倩