【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】
