SSO 單點(diǎn)登錄和 OAuth2.0 的區(qū)別

這是在工作中經(jīng)常遇到的兩個(gè)概念，但還有一些同學(xué)不是很理解，這篇文章就來(lái)詳細(xì)說(shuō)說(shuō)。

轉(zhuǎn)載信息如下：

作者：ximeneschen
鏈接：https://ximeneschen.blog.csdn.net/article/details/115182080

SSO 是 Single Sign On 的縮寫(xiě)，OAuth 是 Open Authority 的縮寫(xiě)，這兩者都是使用令牌的方式來(lái)代替用戶密碼訪問(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)都能免登錄訪問(wèn)資源。

OAuth2.0 原理可能比較陌生，但平時(shí)用的卻很多，比如訪問(wèn)某網(wǎng)站想留言又不想注冊(cè)時(shí)使用了微信授權(quán)。

以上兩者，你在業(yè)務(wù)系統(tǒng)中都沒(méi)有賬號(hào)和密碼，賬號(hào)密碼是存放在登錄中心或微信服務(wù)器中的，這就是所謂的使用令牌代替賬號(hào)密碼訪問(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)這種思想的一種框架而已。

上面的流程大概為：

1. 用戶輸入網(wǎng)址進(jìn)入業(yè)務(wù)系統(tǒng) Protected App，系統(tǒng)發(fā)現(xiàn)用戶未登錄，將用戶重定向到單點(diǎn)登錄系統(tǒng) CAS Server，并帶上自身地址 service 參數(shù)
2. 用戶瀏覽器重定向到單點(diǎn)登錄系統(tǒng)，系統(tǒng)檢查該用戶是否登錄，這是 SSO（這里是 CAS）系統(tǒng)的第一個(gè)接口，該接口如果用戶未登錄，則將用戶重定向到登錄界面，如果已登錄，則設(shè)置全局 session，并重定向到業(yè)務(wù)系統(tǒng)
3. 用戶填寫(xiě)密碼后提交登錄，注意此時(shí)的登錄界面是 SSO 系統(tǒng)提供的，只有 SSO 系統(tǒng)保存了用戶的密碼
4. SSO 系統(tǒng)驗(yàn)證密碼是否正確，若正確則重定向到業(yè)務(wù)系統(tǒng)，并帶上 SSO 系統(tǒng)的簽發(fā)的 ticket
5. 瀏覽器重定向到業(yè)務(wù)系統(tǒng)的登錄接口，這個(gè)登錄接口是不需要密碼的，而是帶上 SSO 的 ticket，業(yè)務(wù)系統(tǒng)拿著 ticket 請(qǐng)求 SSO 系統(tǒng)，獲取用戶信息。并設(shè)置局部 session，表示登錄成功返回給瀏覽器 sessionId
6. 之后所有的交互用 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.0 中，有授權(quán)服務(wù)器、資源服務(wù)器、客戶端這樣幾個(gè)角色，當(dāng)我們用它來(lái)實(shí)現(xiàn) SSO 的時(shí)候是不需要資源服務(wù)器這個(gè)角色的，有授權(quán)服務(wù)器和客戶端就夠了。

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

1. 用戶在某網(wǎng)站上點(diǎn)擊使用微信授權(quán)，這里的某網(wǎng)站就類(lèi)似業(yè)務(wù)系統(tǒng)，微信授權(quán)服務(wù)器就類(lèi)似單點(diǎn)登錄系統(tǒng)
2. 之后微信授權(quán)服務(wù)器返回一個(gè)確認(rèn)授權(quán)頁(yè)面，類(lèi)似登錄界面，這個(gè)頁(yè)面當(dāng)然是微信的而不是業(yè)務(wù)系統(tǒng)的
3. 用戶確認(rèn)授權(quán)，類(lèi)似填寫(xiě)了賬號(hào)和密碼，提交后微信鑒權(quán)并返回一個(gè) ticket，并重定向業(yè)務(wù)系統(tǒng)。
4. 業(yè)務(wù)系統(tǒng)帶上 ticket 訪問(wèn)微信服務(wù)器，微信服務(wù)器返回正式的 token，業(yè)務(wù)系統(tǒng)就可以使用 token 獲取用戶信息了

簡(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è)中間步驟，所以稱為（授權(quán)碼）“隱藏式”（implicit）。

密碼式（password）

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

客戶端憑證（client credentials）

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

總結(jié)

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

其次，OAuth2.0 是用來(lái)允許用戶授權(quán)第三方應(yīng)用訪問(wèn)他在另一個(gè)服務(wù)器上的資源的一種協(xié)議，它不是用來(lái)做單點(diǎn)登錄的，但我們可以利用它來(lái)實(shí)現(xiàn)單點(diǎn)登錄。

在實(shí)現(xiàn) SSO 的過(guò)程中，受保護(hù)的資源就是用戶的信息（包括，用戶的基本信息，以及用戶所具有的權(quán)限），而我們想要訪問(wèn)這一資源就需要用戶登錄并授權(quán)，OAuth2.0 服務(wù)端負(fù)責(zé)令牌的發(fā)放等操作，這令牌的生成我們采用 JWT，也就是說(shuō) JWT 是用來(lái)承載用戶的 Access_Token 的。

以上就是本文的全部?jī)?nèi)容，如果覺(jué)得還不錯(cuò)的話歡迎點(diǎn)贊，轉(zhuǎn)發(fā)和關(guān)注，感謝支持。

推薦閱讀：

• Git 分支管理策略