我应该对本地桌面应用程序的OpenID Connect使用PKCE吗？

Question

我想对我的本机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指出，除了确保同一设备上的另一个应用程序已经注册了该应用程序外，它并没有带来任何额外的安全性。相同的Private-Use URI Scheme Redirect。

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

Answer 1

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

从协议角度看，PKCE已成为强制性的。正在新的RFC（draft-ietf-oauth-security-topics-12）下对此进行讨论，该RFC即将面世。使用PKCE，您可以避免将授权代码丢失给最终用户计算机中运行的恶意应用程序。

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

对于本机应用程序，自定义url方案的注册是获取授权响应的理想方法。并指出，将其与PKCE结合使用。

Answer 2

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

加里，随时给我发任何后续问题