【.com快译】各位小伙伴们，你是不是和身边很多开发者一样经常把OAuth2.0（以下简称OAuth）和Web会话管理混淆？你错了吗？乱用协议和技术栈，引发各种安全问题？本文将与您讨论何时使用常规会话管理解决方案，以及何时使用某种OAuth流程。主要区别一般来说，用户会话管理和OAuth之间的区别主要在于通信双方之间的信任级别。当我们处理用户会话时，我们通常假设通信中的一方不可信任（例如：您的应用程序的前端），而另一方可以信任（例如：您的应用程序的后端）。而在OAuth流程中，通信的双方都是可信的（例如：您的应用程序的后端和第三方应用程序的后端）。当然，在某些OAuth流程中，通信的一方可能不可信。那么在这种情况下，我们将需要一个“短暂的”握手。下面我们主要讨论双方都被信任的情况。可以看出会话管理一般是指：自己应用的后台和前台之间的通信。而OAuth是指：当你的应用程序（前端或后端）需要与第三方应用程序的后端通信时（例如：使用Google/Facebook登录你自己的应用程序），使用Okta/Auth0来管理用户。以全球贸易为例，OAuth可以看作是允许国家间贸易的系统，会话管理是允许国家内部贸易的系统。无论您是否需要与其他国家/地区交换商品（数据），您始终需要进行本地贸易（我们将在“会话管理决定OAuth”一节中更详细地讨论这一点）。关于信任一般来说，我们认为后端往往可以被应用程序开发人员严格控制，值得用户和其他应用程序的信任。当然，后端也可能发生数据泄露和内部威胁。但是，与最终用户计算机上的恶意软件等相比，这些安全事件对于应用程序开发人员来说是“可控的”。相反，由于前端设备可能会受到社会工程技术或恶意软件工具的危害，因此应用程序人员无法预见性地采取任何措施来缓解或管理此类情况。因此，我们可以简单地认为：在任何应用中，前端都是不可信的，而后端是可信的。由此可见，我们不能盲目相信前端传来的数据，而必须时刻对传入的数据进行验证和“清洗”，将风险降到最低。会话管理决定OAuth为了说明这种依赖关系，我们假设有两个应用程序：YourApp和OtherApp，它们使用授权代码（Authorizationcode）流来相互通信。为简洁起见，我们省略了通过客户端密钥或用于代码交换的代码交换证明密钥(PKCE)授权代码的步骤。YourApp有以下组件：UntrustedfrontendOptionalbackendserverOtherApp有以下组件：UntrustedfrontendBackend接下来我们看看不同的访问方式：(1)YourApp有一个后端服务器a)YourApp的前端需要访问YourApp的后台服务器b)YourApp的前后台需要访问OtherApp的后台服务器。(2)YourApp没有后端服务器a)YourApp的前端需要访问OtherApp的后端服务器访问方式1.a)如上图所示，其中一种方法是简单的使用前后端之间的session管理。当然，如果使用Okta或Auth0等外部身份管理方案，可以使用如下方法：YourApp前端将用户重定向到OtherApp（如图1.1所示）。在这里，用户登录到OtherApp的前端，它通过会话管理与后端对话（如图1.2所示）。验证成功后，OtherApp的后台会下发一个shortlivedaccesstoken（因为无法确定前端是否可以安全存储不变的longlivedrefreshtoken），并存储在YourApp的前端。YourApp的前端然后使用该访问令牌与YourApp的后端对话。该访问令牌过期后，该用户将被重定向到OtherApp的前端。如果OtherApp的前端和后端之间的会话仍然有效，YourApp的前端将立即通过授权码颁发一个新的访问令牌。否则，用户必须重新登录。接入方式1.b)用户通过YourApp前端登录到YourApp后端。两者之间的数据通过会话管理进行交换。用户在OtherApp的前端验证自己（重定向到图2.1）。同时，OtherApp前端通过会话管理与后端进行通信（如图2.2所示）。身份验证成功后，OtherApp的后端将发出一个短期访问令牌（存储在YourApp的前端和/或后端）和一个长期刷新令牌（仅存储在YourApp的受信任后端）。YourApp的前端/后端然后可以使用访问令牌与OtherApp的后端对话。在该访问令牌过期后，YourApp的后端可以使用该刷新令牌获取新的访问令牌，并将其发送到YourApp的前端。访问方式2.a)YourApp前端将用户重定向到OtherApp（如图1.1所示）。在这里，用户登录到OtherApp的前端，它通过会话管理与后端对话（如图1.2所示）。验证成功后，OtherApp的后台会下发一个shortlivedaccesstoken（因为无法确定前端是否可以安全存储不变的longlivedrefreshtoken），并存储在YourApp的前端。YourApp的前端然后使用该访问令牌与OtherApp的后端对话。该访问令牌过期后，该用户将被重定向到OtherApp的前端。如果OtherApp的前端和后端之间的会话仍然有效，YourApp的前端将立即通过授权码颁发一个新的访问令牌。否则，用户必须重新登录。至此不难看出，无论两个应用程序如何相互通信，始终需要进行会话管理。不同类型的令牌正如上面分析中提到的，Oauth使用短期访问令牌和长期刷新令牌。而会话管理只需要一个“一次性使用”刷新令牌（也称为旋转刷新令牌，请参阅--https://tools.ietf.org/html/rfc6819#section-5.2.2.3），以发送和存储在前端。有关会话流的安全分析，请参阅https://bit.ly/2LoHzTT。此外，OAuth和会话管理使用不同类型的令牌。在OAuth中，如果使用OtherApp颁发的accesstoken作为YourApp前后端的通信，则该token必须是JWT。据此，YourApp的后端可以验证令牌，而无需调用OtherApp的后端。事实上，JWT正是为了满足这种需求而发明的。在会话管理中，访问令牌可以是不透明的（长随机字符串）或JWT。它们在具体使用中的优缺点可以参考文章--《你需要知道的用户会话安全都在这里!》(https://netsecurity.51cto.com/art/202006/617887.htm)。总结OAuth和会话管理之间的核心区别在于信任。使用会话管理，我们可以在不受信任方（前端）和受信任方（在同一应用程序内）之间保持长期连接。使用OAuth，可以在两个受信任方（通常是不同服务的后端）之间维持一个长期存在的、经过身份验证的连接。原标题：OAuth2.0vsSessionManagement，作者：AdvaitRuia
