一、概述

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

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

二、SSO

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

上面的流程大概為：

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

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

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

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

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

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

最常見(jiàn)的例子是，我們打開(kāi)淘寶APP，首頁(yè)就會(huì)有天貓、聚劃算等服務(wù)的鏈接，當(dāng)你點(diǎn)擊以后就直接跳過(guò)去了，并沒(méi)有讓你再登錄一次

三、OAuth2.0

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

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

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

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

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

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

簡(jiǎn)介一下OAuth2.0的四種模式：

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

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

隱藏式（implicit）

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

密碼式（password）

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

客戶(hù)端憑證（client credentials）

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

簡(jiǎn)單流程

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

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

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

最后，Spring Security、Shiro是用于安全訪(fǎng)問(wèn)的，用來(lái)做訪(fǎng)問(wèn)權(quán)限控制，都是一個(gè)用Java寫(xiě)的框架

審核編輯 ：李倩