关于Windows:在Web应用程序和本机应用程序之间组织安全通道

Organizing a secure channel between a Web app and a Native app

这个问题是对"在本机应用程序和网站之间共享凭据"的补充,因为我们的目标是在相反的方向上共享机密。

TL; TR:我们如何安全地从Web浏览器应用程序向Native Desktop应用程序共享用户的身份验证/授权状态,因此同一用户不必在Native应用程序中另外进行身份验证?

TS; WM:我们正在研究以下体系结构:Web应用程序(在用户选择的Web浏览器中运行着一些HTML前端UI),本机桌面应用程序(实现自定义协议处理程序),Web API和OAuth2服务,如图所示。

> </p>
<p>最初,使用授权代码授予流程针对OAuth2服务在Web浏览器应用程序中对用户进行身份验证/授权。 </p>
<p>然后,当用户单击我们的基于协议的自定义超链接时,Web浏览器内容可以与本机应用程序进行单向对话。基本上,已经完成了通过Web API在两者之间建立安全的双向后端通信通道的操作。</p>
<p>我们相信,在对通过自定义协议链接从Web浏览器应用程序收到的任何请求采取行动之前,本机应用程序应首先对用户进行身份验证(使用该特定的桌面会话该用户应该是同一个人)。我们认为本机应用程序还应该使用授权码流(带有PKCE)来获取Web API的访问令牌。然后,它应该能够使用相同的Web API安全地验证自定义协议数据的来源和完整性。</p>
<p>但是,用户必须两次通过身份验证才能同时进行两次身份验证,这对用户来说是一次阻碍的体验。</p>
<p>因此,问题是:有没有办法在不影响此体系结构的客户端安全性的情况下,将OAuth2访问令牌(或任何其他授权承载)从Web浏览器应用安全地传递到本机应用?也就是说,Native应用程序可以使用Web浏览器中的身份调用Web API,而不必先验证同一用户? </p>
<p><center> <script src=

就我个人而言,我看不到如何安全地避免这种额外的身份验证流程。默认情况下,通过自定义应用程序协议进行的通信是不安全的,因为通常这只是调用本机应用程序的命令行参数。与TLS通道不同,它可以被拦截,模拟等。我们可以对自定义协议数据进行加密。尽管如此,无论对本机应用程序进行何种调用来解密(无论是对客户端OS API还是对Web API的一些不受保护的调用),坏的actor /恶意软件也可能能够复制这些内容。

我错过了什么吗?是否有特定于平台的安全解决方案?本机桌面应用程序是Electron应用程序,旨在跨平台。我们的大多数用户都可以使用任何受支持的浏览器(甚至包括IE11)在Windows上运行此程序,但是毫无疑问ActiveX或入侵正在运行的Web浏览器实例。


最佳解决方案:使用自定义URL方案的单点登录(SSO)

当我检查您的问题时,我想起了我在办公室中使用的Zoom应用程序。它是如何工作的?

我的Gmail帐户已链接到Zoom帐户(这是帐户链接,这不在实施范围之内)。打开"缩放"应用程序时,我可以选择使用Gmail登录的选项。这将打开我的浏览器,并带我到Gmail。如果我登录到Gmail,则会重定向回到要求我启动Zoom应用程序的页面。这个应用程式如何启动?安装应用后,该应用会注册一个自定义URL方案,并且浏览器中的最终重定向将以该URL为目标。并且此URL传递了一个临时机密,Zoom应用程序使用该机密来获取OAuth令牌。并且令牌获取是独立于浏览器完成的,使用SSL直接调用OAuth服务器的令牌端点。

这是本机应用程序的授权代码流。这就是移动应用程序使用OAuth的方式。您的主要问题(不允许用户重新登录)已解决。这是正在执行的SSO。

有一个规范定义了围绕此机制的最佳实践。欢迎您阅读RFC8252-适用于本机应用程序的OAuth 2.0。

挑战

您需要为每个应用程序分发实施特定于OS的本机代码。 Windows,Mac和Linux对自定义URL方案具有不同的实现支持。

建议

对于所有OAuth授予类型,

PKCE是强制性的(应在IETF单词中)。正在进行的草案对此进行了讨论。因此,也应将PKCE包含在您的实现中。

How

使用PKCE,可以防止重定向/回调响应被窃取。甚至其他一些应用程序也截获了回调,因为PKCE code_verifer存在,所以无法重新创建令牌请求。

此外,请勿使用自定义解决方案,例如通过其他渠道传递机密。在维护方面,这会使事情变得复杂。由于该流已存在于OAuth中,因此您可以受益于库和指南。

--------------------------------------------------- ------

更新:保护令牌请求

尽管自定义URL方案解决了启动本机应用程序的问题,但是保护令牌请求可能是一项挑战。有几个选项可供考虑。

-使用从浏览器共享的机密绑定本机应用程序启动

当基于浏览器的客户端启动本机客户端时,它可以调用自定义API来生成机密。此机密就像是一次性密码(OTP)。用户必须先在本机应用中输入此值,然后才能获取令牌。这是在授权代码流之上的自定义。

-动态客户端注册


n


n


只是有以下想法。这很简单,虽然不允许完全自动设置Web浏览器应用程序与本机应用程序之间的安全通道,但它可能会大大改善用户体验。

我们可以使用基于时间的一次性密码算法(TOTP)。在某种程度上,它类似于我们将蓝牙键盘与计算机或电话配对的方式。

Web浏览器应用程序(用户已通过身份验证)可以向用户显示基于时间的代码,本机应用程序应要求用户输入该代码作为确认。然后,它将使用该代码针对Web API进行身份验证。这足以在两者之间建立后端通道。频道的生命周期应限制为Web浏览器应用程序中会话的生命周期。首先,这种方法甚至可以消除对自定义协议通信的需求。

仍然欢迎其他想法。


正如您提到的,使用自定义协议处理程序不是传递秘密的安全方法,因为另一个应用程序可能会处理您的协议并拦截该秘密。

如果您施加严格限制,则本机应用程序与Web应用程序之间的通信通道是从Web应用程序启动的,并且本机应用程序以前未建立安全通道(例如,可以对其他机密进行加密的共享机密) ),则无法将机密安全地传输到本机应用。

想象一下,如果可能的话,那么PKCE在OAuth 2.0代码流中将是多余的,因为服务器可以响应授权请求安全地传输访问令牌,而不需要为code_verifier提供获取访问令牌时授予。