请别再混淆OAuth20和会话管理了

朋友,您是否和周围许多开发人员一样,时常将OAuth2.0(以下简称OAuth)与Web会话管理相混淆?您是否因为错误地使用协议和技术栈,而导致各种安全问题呢?本文将和您讨论何时该使用常规的会话管理解决方案,以及何时该使用某种OAuth流。主要区别总的说来,用户会话管理和OAuth之间的区别主要体现在通信双方之间的信任级别上。我们在使用用户会话时,通常假定通信中的一方是不可信任的(例如:您应用程序的前端),而另一方是可以信任的(例如:您应用程序的后端)。而在OAuth流中,通信的双方都是受到信任的(例如:您应用程序的后端和第三方应用程序的后端)。当然,在某些OAuth流中,通信的某一方可能不受信任。那么在这种情况下,我们会需要“shortlived”握手。下面我们主要讨论的还是双方受信任的情况。可见,会话管理通常是指:您自己应用的后端和前端之间的通信。而OAuth是指:在您的应用(前端或后端)需要与第三方应用(例如:使用Google/Facebook登录到您自己的应用)的后端通信时,使用Okta/Auth0来管理用户。让我们以全球贸易为例,OAuth可以被看作是允许国家之间进行贸易的系统,而会话管理则是可以在国家内部进行贸易的系统。无论您是否需要与其他国家/地区交换商品(数据),您始终需要进行本地贸易(我们会在“会话管理决定OAuth”部分详细讨论)。有关信任通常,我们认为后端往往能够受到应用开发人员的严格管控,值得用户和其他应用程序的信任。当然,后端也可能发生数据泄露和内部威胁。不过,与诸如最终用户电脑上的恶意软件相比,这些安全事件对于应用开发人员来说算是“可控”的。相反,由于前端设备可能会受到社会工程技术、或恶意软件的工具,应用程序人员无法预见性地采取任何措施来缓解或管控此类情况。因此,我们可以简单地认为:在任何应用中,前端都是不受信任的,而后端是受信任的。可见,我们不能够盲目地信任从前端发送的数据,而必须始终验证和“消毒”传入的数据,将风险降至最低。会话管理决定OAuth为了说清楚这种依赖关系,让我们假设有两个应用程序:YourApp和OtherApp,它们使用授权代码(Authorisationcode)流,来实现彼此通信。为简便起见,我们省去了通过客户端密码、或用于代码交换的证明密钥(ProofKeyforCodeExchange,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的后端会发出一个shortlived的访问令牌(因为它不能确定前端是否能够安全地存储不变的longlived刷新令牌),并存储在YourApp的前端。接着,YourApp的前端使用该访问令牌与YourApp的后端进行对话。该访问令牌过期后,此用户将被重定向到OtherApp的前端。如果OtherApp的前端和后端之间的会话还有效,那么YourApp的前端会通过授权码,立即颁发一个新的访问令牌。否则,用户就必须重新登录。访问模式1.b)用户通过YourApp的前端登录到YourApp的后端。两者之间的数据,通过会话管理来进行交换。用户在OtherApp的前端(被重定向到如图2.1处)进行自我身份验证。同时,OtherApp的前端通过会话管理(如图2.2处)与后端进行对话。验证成功后,OtherApp的后端会发出一个shortlived的访问令牌(存储在YourApp的前端和/或后端)、以及一个longlived的刷新令牌(仅存储在YourApp受信任的后端)。接着,YourApp的前端/后端可以使用访问令牌与OtherApp的后端进行对话。该访问令牌过期后,YourApp的后端可以使用该刷新令牌来获取新的访问令牌,将其发送到YourApp的前端。访问模式2.a)YourApp的前端将用户重定向到OtherApp(如图1.1处)。在此,用户登录到OtherApp的前端,该前端通过会话管理(如图1.2处)与后端进行对话。验证成功后,OtherApp的后端会发出一个shortlived的访问令牌(因为它不能确定前端是否能够安全地存储不变的longlived刷新令牌),并存储在YourApp的前端。接着,YourApp的前端使用该访问令牌与OtherApp的后端进行对话。该访问令牌过期后,此用户将被重定向到OtherApp的前端。如果OtherApp的前端和后端之间的会话还有效,那么YourApp的前端会通过授权码,立即颁发一个新的访问令牌。否则,用户就必须重新登录。至此,我们不难看出,无论两个应用如何相互通信,都始终需要会话的管理。令牌的不同类型正如上文分析中所提到的,Oauth采用了shortlived访问令牌和longlived刷新令牌。而会话管理只需要“一次性地使用”刷新令牌(也称为旋转刷新令牌),以发送并存储在前端。此外,OAuth和会话管理还使用到了不同类型的令牌。在OAuth中,如果OtherApp发出的访问令牌,被用于YourApp的前端和后端之间的通信,则此令牌必须是JWT。据此,YourApp的后端可以验证该令牌,且不必调用OtherApp的后端。实际上,JWT就是为了满足这一确切需求而发明的。在会话管理中,访问令牌既可以是Opaque(一种长随机字符串),又可以是JWT。它们在具体使用中的优点和缺点,请参见--《你需要知道的用户会话安全都在这里!》一文。总结OAuth和会话管理之间的核心区别是在信任上。使用会话管理,我们可以在不受信任的一方(前端)和受信任的一方(同一个应用的内部)之间维持长期有效的连接。而使用OAuth,则可以在两个受信方(通常是不同服务的后端)之间,维持长期的、经过身份验证的连接。


转载请注明:http://www.aierlanlan.com/rzfs/6357.html