我应该将 PKCE 用于 OpenID Connect 与本机桌面应用程序吗？答案

【问题标题】：Should I use PKCE for OpenID Connect with Native Desktop Application?我应该将 PKCE 用于 OpenID Connect 与本机桌面应用程序吗？
【发布时间】：2019-09-21 01:03:59
【问题描述】：

我想为我的本地 Windows 和 Linux 桌面应用程序使用 OpenID Connect 来验证我的用户。

如"OAuth 2.0 for Native Apps" Section 7.3 中所述，我想从身份验证服务器打开一个本地 TCP 端口重定向以获取授权码。我认为对于适用于 Windows 和 Linux 的本机应用程序没有其他选择。

所以流程是这样的：

原生应用启动并显示登录按钮
按下登录按钮时

原生应用打开一个临时的本地端口
浏览器打开并显示身份验证提供程序的登录页面（连同客户端 ID 和密码、重定向 URI 和范围 openid、response_type=code 一起发送）

在浏览器中成功验证用户后

身份验证提供程序重定向到重定向 URI，即本地开放端口
本地端口应该向用户显示类似“立即关闭浏览器并返回应用程序”的内容

本机应用程序从重定向获取代码并关闭端口
本机应用程序要求令牌端点使用代码获取身份令牌

使用签名验证身份令牌
将能够从该身份令牌中获取用户的详细信息

我现在的问题是我需要 PKCE 吗？我发现 this article 指出它不会带来任何额外的安全性，除了确保同一设备上的另一个应用程序注册相同 @ 987654323@.

我的计划是否存在任何其他方面的缺陷或需要进一步改进？我了解客户端 ID 和机密可以被视为“公开”，因为它们随软件一起提供并且可以被逆向工程。但是我的软件将不会在公共网页上（希望如此）提供，并且只会提供给受信任的客户（他们都有不同的客户端 ID 和机密）。

【问题讨论】：

标签： authentication openid-connect nativeapplication pkce

【解决方案1】：

OAuth 和原生应用程序带来了一些复杂性。这是因为本机应用程序在本地运行，而 OAuth 依赖于浏览器来完成流程。首先，欢迎大家关注other questions and answers，其中讨论了与原生应用程序相关的技术。

从协议的角度来看，PKCE 已经成为强制性的。这将在即将推出的新 RFC (draft-ietf-oauth-security-topics-12) 下进行讨论。使用 PKCE，您可以避免将授权代码丢失给在最终用户机器上运行的恶意应用程序。

原因是，从授权服务器，它只依赖客户端 ID 和重定向 URL 来识别正确的客户端。因此，如果授权响应被拦截，那么任何一方都可以获得令牌。 PKCE 通过引入在运行时生成的安全随机密钥来避免这种情况。这不会被存储，只会在受 SSL 保护的令牌请求中进行通信。因此，PKCE 减少了窃取令牌的威胁向量。

对于原生应用，注册自定义 url 方案是获取授权响应的完美方式。正如规范所指出的，将它与 PKCE 结合起来。

【讨论】：

感谢您的回答！在我的具体情况下，我需要使用 QtNetworkAuth 将它实现到现有的 C++ Qt 应用程序中，它应该在 Windows 和 Linux 上运行。因此，我认为在重定向到 IdP 之前使用环回并专门注册端口可能更容易，因此没有其他应用程序可以执行 MitM。使用环回变体时我没有看到攻击面，你能解释一下吗？正如我所见，PKCE 是强制性的（也用于环回），并且隐式流现在已被 SPA 弃用。
PKCE 是 MitM 的计数器测量值。因此，即使另一个应用程序尝试捕获环回传输的数据，它也无法获取令牌。令牌请求受原始应用程序生成的运行时机密保护。是的，隐式流量根据突出显示的规范进行折旧。
对我来说不同之处在于 URI 方案允许其他应用程序注册它并获取获取令牌的代码，因此在这种情况下 PKCE 对我来说非常有意义。但是当应用程序在本地机器上独占打开一个端口时，没有其他应用程序可以获取代码。为了确保在我的应用程序之前未注册端口，我会在重定向到 IdP 之前注册，否则会在我的应用程序中显示错误。
@jcrosel 好吧，你的方法可以工作。但我怀疑这将如何与重定向 URL 注册一起使用。授权服务器要求您的应用程序在使用协议（例如：OAuth 或 OpenID Connect）之前进行注册。在此注册中，重定向 URL 是一个关键元素。因此，如果您动态使用 PORT，那么上述注册可能会出现问题。无论如何，主要的 OAuth 库已经实现了 PKCE。所以你不必太担心实施。

【解决方案2】：

我也很难理解桌面流程。我建议将私有 uri 方案作为最佳解决方案 - 从这里开始，我有一些跨平台的文章，可能会给你一些想法： https://authguidance.com/2018/01/11/desktop-apps-overview/

如有任何后续问题，请随时联系我，Gary

【讨论】：

我不知道本机应用程序可以为 OAuth 使用 URI 方案，因为 RFC 声明“传统应用程序通常使用环回重定向”和“UWP 应用程序可以使用私有使用 URI 方案重定向” .您是否在本机桌面应用程序上为 Windows 和 Linux 注册了私有 URI 方案？您的示例 SPA 跨平台应用程序 (authguidance.com/2017/09/26/basicspa-oauthworkflow) 使用环回端口方法
总而言之，对于本机桌面应用程序，您可以使用环回端口或私有 URI 方案 - 两者都是不错的选择（都使用 PKCE，如上所述）。 GitHub Desktop 是使用私有 URI 方案的本机应用程序的一个很好的例子（Dominick Baier 不久前向我指出，我更喜欢这个选项）。在我的上一家公司，我们做了几个 OAuth 安全的 Electron 桌面应用程序，我写了很多关于它的东西 - 这是一篇关于私有 URI 方案的截图：(authguidance.com/2018/01/26/final-desktop-sample-overview)