【51CTO.com快譯】朋友，您是否和周圍許多開發(fā)人員一樣，時常將OAuth 2.0(以下簡稱OAuth)與Web會話管理相混淆?您是否因為錯誤地使用協(xié)議和技術(shù)棧，而導(dǎo)致各種安全問題呢?本文將和您討論何時該使用常規(guī)的會話管理解決方案，以及何時該使用某種OAuth流。

主要區(qū)別

總的說來，用戶會話管理和OAuth之間的區(qū)別主要體現(xiàn)在通信雙方之間的信任級別上。

我們在使用用戶會話時，通常假定通信中的一方是不可信任的(例如：您應(yīng)用程序的前端)，而另一方是可以信任的(例如：您應(yīng)用程序的后端)。而在OAuth流中，通信的雙方都是受到信任的(例如：您應(yīng)用程序的后端和第三方應(yīng)用程序的后端)。當(dāng)然，在某些OAuth流中，通信的某一方可能不受信任。那么在這種情況下，我們會需要“short lived”握手。下面我們主要討論的還是雙方受信任的情況。

可見，會話管理通常是指：您自己應(yīng)用的后端和前端之間的通信。而OAuth是指：在您的應(yīng)用(前端或后端)需要與第三方應(yīng)用(例如：使用Google/Facebook登錄到您自己的應(yīng)用)的后端通信時，使用Okta/Auth0來管理用戶。

讓我們以全球貿(mào)易為例，OAuth可以被看作是允許國家之間進(jìn)行貿(mào)易的系統(tǒng)，而會話管理則是可以在國家內(nèi)部進(jìn)行貿(mào)易的系統(tǒng)。無論您是否需要與其他國家/地區(qū)交換商品(數(shù)據(jù))，您始終需要進(jìn)行本地貿(mào)易(我們會在“會話管理決定OAuth”部分詳細(xì)討論)。

有關(guān)信任

通常，我們認(rèn)為后端往往能夠受到應(yīng)用開發(fā)人員的嚴(yán)格管控，值得用戶和其他應(yīng)用程序的信任。當(dāng)然，后端也可能發(fā)生數(shù)據(jù)泄露和內(nèi)部威脅。不過，與諸如最終用戶電腦上的惡意軟件相比，這些安全事件對于應(yīng)用開發(fā)人員來說算是“可控”的。相反，由于前端設(shè)備可能會受到社會工程技術(shù)、或惡意軟件的工具，應(yīng)用程序人員無法預(yù)見性地采取任何措施來緩解或管控此類情況。因此，我們可以簡單地認(rèn)為：在任何應(yīng)用中，前端都是不受信任的，而后端是受信任的?？梢?，我們不能夠盲目地信任從前端發(fā)送的數(shù)據(jù)，而必須始終驗證和“消毒”傳入的數(shù)據(jù)，將風(fēng)險降至最低。

會話管理決定OAuth

為了說清楚這種依賴關(guān)系，讓我們假設(shè)有兩個應(yīng)用程序：YourApp和OtherApp，它們使用授權(quán)代碼(Authorisation code)流，來實現(xiàn)彼此通信。為簡便起見，我們省去了通過客戶端密碼、或用于代碼交換的證明密鑰(Proof Key for Code Exchange，PKCE)等授權(quán)代碼的步驟。

YourApp具有如下組件：

• 不受信任的前端
• 可選的后端服務(wù)器

OtherApp具有如下組件：

• 不受信任的前端
• 后端

下面，讓我們看看不同的訪問模式：

(1) YourApp擁有一個后端服務(wù)器

• a) YourApp的前端需要訪問YourApp的后端服務(wù)器
• b) YourApp的前/后端需要訪問OtherApp的后端服務(wù)器。

(2) YourApp沒有后端服務(wù)器

• a) YourApp的前端需要訪問OtherApp的后端服務(wù)器

訪問模式1. a)

如上圖所示，其中的一種方法是在前端和后端之間簡單地使用會話管理。當(dāng)然，如果您使用到了諸如Okta或Auth0之類的外部身份管理方案，則可以采用如下方法：

• YourApp的前端將用戶重定向到OtherApp(如圖1.1處)。在此，用戶登錄到OtherApp的前端，該前端通過會話管理(如圖1.2處)與后端進(jìn)行對話。
• 驗證成功后，OtherApp的后端會發(fā)出一個short lived的訪問令牌(因為它不能確定前端是否能夠安全地存儲不變的long lived刷新令牌)，并存儲在YourApp的前端。
• 接著，YourApp的前端使用該訪問令牌與YourApp的后端進(jìn)行對話。
• 該訪問令牌過期后，此用戶將被重定向到OtherApp的前端。如果OtherApp的前端和后端之間的會話還有效，那么YourApp的前端會通過授權(quán)碼，立即頒發(fā)一個新的訪問令牌。否則，用戶就必須重新登錄。

訪問模式1. b)

• 用戶通過YourApp的前端登錄到Y(jié)ourApp的后端。兩者之間的數(shù)據(jù)，通過會話管理來進(jìn)行交換。
• 用戶在OtherApp的前端(被重定向到如圖2.1處)進(jìn)行自我身份驗證。同時，OtherApp的前端通過會話管理(如圖2.2處)與后端進(jìn)行對話。
• 驗證成功后，OtherApp的后端會發(fā)出一個short lived的訪問令牌(存儲在YourApp的前端和/或后端)、以及一個long lived的刷新令牌(僅存儲在YourApp受信任的后端)。
• 接著，YourApp的前端/后端可以使用訪問令牌與OtherApp的后端進(jìn)行對話。
• 該訪問令牌過期后，YourApp的后端可以使用該刷新令牌來獲取新的訪問令牌，將其發(fā)送到Y(jié)ourApp的前端。

訪問模式2. a)

• YourApp的前端將用戶重定向到OtherApp(如圖1.1處)。在此，用戶登錄到OtherApp的前端，該前端通過會話管理(如圖1.2處)與后端進(jìn)行對話。
• 驗證成功后，OtherApp的后端會發(fā)出一個short lived的訪問令牌(因為它不能確定前端是否能夠安全地存儲不變的long lived刷新令牌)，并存儲在YourApp的前端。
• 接著，YourApp的前端使用該訪問令牌與OtherApp的后端進(jìn)行對話。
• 該訪問令牌過期后，此用戶將被重定向到OtherApp的前端。如果OtherApp的前端和后端之間的會話還有效，那么YourApp的前端會通過授權(quán)碼，立即頒發(fā)一個新的訪問令牌。否則，用戶就必須重新登錄。

至此，我們不難看出，無論兩個應(yīng)用如何相互通信，都始終需要會話的管理。

令牌的不同類型

正如上文分析中所提到的，Oauth采用了short lived訪問令牌和long lived刷新令牌。而會話管理只需要“一次性地使用”刷新令牌(也稱為旋轉(zhuǎn)刷新令牌，請參見--

https://tools.ietf.org/html/rfc6819#section-5.2.2.3)，以發(fā)送并存儲在前端。有關(guān)會話流的安全性分析，請參見--https://bit.ly/2LoHzTT。

此外，OAuth和會話管理還使用到了不同類型的令牌。在OAuth中，如果OtherApp發(fā)出的訪問令牌，被用于YourApp的前端和后端之間的通信，則此令牌必須是JWT。據(jù)此，YourApp的后端可以驗證該令牌，且不必調(diào)用OtherApp的后端。實際上，JWT就是為了滿足這一確切需求而發(fā)明的。

在會話管理中，訪問令牌既可以是Opaque(一種長隨機(jī)字符串)，又可以是JWT。它們在具體使用中的優(yōu)點和缺點，請參見--《你需要知道的用戶會話安全都在這里!》一文

(https://netsecurity.51cto.com/art/202006/617887.htm)。

總結(jié)

OAuth和會話管理之間的核心區(qū)別是在信任上。使用會話管理，我們可以在不受信任的一方(前端)和受信任的一方(同一個應(yīng)用的內(nèi)部)之間維持長期有效的連接。而使用OAuth，則可以在兩個受信方(通常是不同服務(wù)的后端)之間，維持長期的、經(jīng)過身份驗證的連接。

原標(biāo)題：OAuth 2.0 vs session Management ，作者: Advait Ruia 

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】