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

Question

这个问题是对“ Share credentials between native app and web site”的补充，因为我们的目的是分享相反的秘密。

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

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

最初，使用授权代码授予流程针对OAuth2服务在Web浏览器应用中对用户进行身份验证/授权。

然后，当用户单击我们的基于协议的自定义超链接时，Web浏览器内容可以与本机应用程序进行单向对话。基本上，已经完成了通过Web API在两者之间建立安全的双向后端通信通道的工作。

我们相信，在处理通过自定义协议链接从Web浏览器应用收到的任何请求之前，本机应用应首先对用户进行身份验证（使用该身份的用户应该是同一个人）特定的桌面会话）。我们认为本机应用程序还应该使用授权码流（带有PKCE）来获取Web API的访问令牌。然后，它应该能够使用相同的Web API安全地验证自定义协议数据的来源和完整性。

但是，对于用户必须两次进行身份验证可能是一种阻碍，首先是在Web浏览器中，第二次是在Native应用程序中，两者同时运行。

因此，问题：是否有一种方法可以安全地将OAuth2访问令牌（或任何其他授权载体）从Web浏览器应用传递到本机应用，而又不会损害此体系结构的客户端安全性？ 也就是说，Native应用程序可以使用Web浏览器中的身份调用Web API，而不必先验证同一用户？

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

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

Answer 1

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

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

想象一下，如果这可能实现，那么PKCE在OAuth 2.0代码流中将是多余的，因为服务器可以安全地传输访问令牌以响应授权请求，而不需要{ {1}}将在获得访问令牌时与授予一起提供。

Answer 2

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

我们可以使用Time-based One-Time Password algorithm (TOTP)。在某种程度上，它类似于我们将蓝牙键盘与计算机或电话配对的方式。

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

仍然欢迎其他想法。

Answer 3

最佳解决方案：使用自定义URL方案的单点登录（SSO）

当我检查您的问题时，我想起了我在办公室中使用的Zoom应用程序。怎么运行的 ？

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

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

有一个规范定义了围绕此机制的最佳实践。欢迎您通过RFC8252 - OAuth 2.0 for Native Apps。

挑战

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

建议

对于所有OAuth授权类型，

PKCE是强制性的（用IETF表示）。 ongoing draft讨论了这一点。因此，也将PKCE包含在您的实现中。

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

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

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

更新：保护令牌请求

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

-将本地应用程序启动与浏览器共享的秘密绑定

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

-动态客户端注册和动态客户端身份验证

OAuth规范不建议将秘密嵌入公共客户端。但正如问题所有者指出的那样，某些恶意应用程序可能会自行注册以接收自定义URL响应并获取令牌。在这种情况下，PKCE可以提供额外的安全性。

但在极端情况下，如果恶意应用程序注册了URL并使用PKCE作为原始应用程序，则可能存在潜在威胁。

一个选项是允许在应用程序首次启动时动态注册客户端。在这里，安装程序/发行版可以包含与DCR一起使用的机密。

此外，可以通过专用服务使用动态客户端身份验证。在此，应用程序的令牌请求包含由自定义服务发出的临时令牌。定制服务面临来自本机应用程序的挑战。这可以通过totp或基于嵌入式机密的密码绑定来完成。也可以使用通过浏览器发布的OTP（如第一个注释中所述），该OTP需要由最终用户手动复制粘贴。验证后，此服务将发出与机密相关的令牌。在令牌请求中，本机客户端将该令牌与回调值一起发送。这样，即使我们增加了实施量，我们也减少了威胁向量。

摘要

• 使用自定义URL方案启动本机应用程序
• 浏览器应用程序生成与自定义服务共享的临时机密
• 启动本机应用程序时，用户应将机密复制到本机应用程序UI
• 本机应用程序将此秘密与定制服务交换以获得令牌
• 第二个令牌与回调授权代码（通过自定义url方案发出）结合使用，用于对令牌端点进行身份验证
• 以上可以视为动态客户端身份验证
• 向用户公开的值可以是哈希值，因此原始值永远不会公开给最终用户或其他客户端
• DCR也是一种选择，但是在OAuth世界中不鼓励使用嵌入式机密

Answer 4

您可以尝试以其他方式驱动同步：

1. 用户通过网络应用程序身份验证后，即可通过自定义URL方案从网络应用程序启动本机应用程序。
2. 如果未对本机应用程序进行身份验证，请通过HTTPS安全地连接到后端，为本机应用程序创建一条记录，检索与该记录关联的一次性令牌，然后在用户的浏览器中使用令牌将Web应用程序启动为URL参数。
3. 由于在浏览器中对用户进行了身份验证，因此当服务器看到令牌时，便可以将本机应用程序的记录与用户帐户绑定。
4. 让本机应用程序轮询（或使用其他实时通道，例如推送通知或TCP连接）在服务器上查看令牌是否已绑定到用户帐户：一旦发生这种情况，您可以传递一个持久的身份验证令牌，本机应用程序可以存储。

Answer 5

您是否考虑过使用operator+或LDAP？

OAuth2也可以结合使用，这是一个相关的问题：
 -Oauth service for LDAP authentication
 -Oauth 2 token for Active Directory accounts

Active Directory应该更容易，而且访问权限可以集中管理。

关于一般安全性考虑，您可以使用两台服务器，并在成功进行访问检查之后将Web应用程序的服务器重定向到另一台。到目前为止，第二台服务器都可以得到保护，以至于需要从第一台服务器进行重定向，并且可以再次进行访问检查，而无需再次登录，因此在此处提及在SSO中的拟议用法可能很重要。 Oracle Access Manager的一个链接答案。
通过在前端使用代理服务器并隐藏重定向，也可以隐藏具有两个服务器的情况，例如，服务器之间的数据传输也将变得更加容易和安全。 关于我的命题的重要一点是，如果出现任何错误并且数据仍然受到保护，则不会授予对第二台服务器的访问权限。

我在这里阅读了一些有关2FA的评论以及诸如令牌之类的其他想法，这些东西肯定会提高安全性，并且实现它们会很好。

如果您喜欢一般的想法，我愿意花一些时间在细节上。一些问题可能对我有用；-）

编辑：
从技术上讲，详细设计可能取决于所使用的perimeter authentication，例如external authentication provider或其他。因此，如果总体而言，该解决方案对您来说合理，那么为选择Oracle Access Manager选择一些参数（例如价格，开源，功能等）会很有用。
但是，然后的一般过程是，提供者发出一个令牌，该令牌用于身份验证。令牌是一次性的唯一用途，我上面发布的第二个链接提供了一些答案，这些答案说明了令牌的使用与安全性和OAuth非常相关。

EDIT2
自己的OAuth2 / OIDC服务器与LDAP / AD服务器之间的区别在于，您需要自己编写所有程序，而不能使用现成的解决方案。不过，您是独立的，并且如果所有程序都编写得当，则可能会更加安全，因为您的解决方案无法公开获得，因此更难破解-其他人无法知道潜在的漏洞。而且，您更加独立，无需等待更新，也可以随时随意更改任何内容。考虑到涉及多个软件服务器，甚至可能涉及硬件服务器，其自己的解决方案可能是有限的可扩展性，但这无法从外部得知，并且取决于您的公司/团队。您的代码库可能比成熟的解决方案薄，因为您只需要考虑自己的解决方案和要求。
解决方案中的弱点可能是您必须对与业务框架准备就绪的几种事物进行接口编程。同样，在一个小型团队中可能很难考虑每个方面，大型公司可能具有更多的概述和能力来解决每个潜在的问题。