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

主要區別

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

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

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

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

有關信任

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

會話管理決定OAuth

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

YourApp具有如下組件：

• 不受信任的前端
• 可選的后端服務器

OtherApp具有如下組件：

• 不受信任的前端
• 后端

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

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

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

(2) YourApp沒有后端服務器

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

訪問模式1. a)

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

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

訪問模式1. b)

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

訪問模式2. a)

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

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

令牌的不同類型

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

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

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

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

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

總結

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

原標題：OAuth 2.0 vs session Management ，作者: Advait Ruia 

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