|
|
51CTO旗下网站
|
|
移动端

请别再混淆OAuth 2.0和会话管理了

您是否和周围许多开发人员一样,时常将OAuth 2.0(以下简称OAuth)与Web会话管理相混淆?本文将和您讨论何时该使用会话管理解决方案,以及何时该使用OAuth流。

作者:陈峻译来源:51CTO|2020-06-11 07:00

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

【责任编辑:赵宁宁 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢
24H热文
一周话题
本月获赞

订阅专栏+更多

实操案例:Jenkins持续交付和持续部署

实操案例:Jenkins持续交付和持续部署

微服务架构下的自动化部署
共18章 | freshman411

144人订阅学习

思科交换网络安全指南

思科交换网络安全指南

安全才能无忧
共5章 | 思科小牛

98人订阅学习

云计算从入门到上瘾

云计算从入门到上瘾

传统IT工程师的转型
共26章 | 51CTO阿森

256人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微