authentication - 我应该将 PKCE 用于 OpenID Connect 与 native 桌面应用程序吗？

Question

我想对我的 native Windows 和 Linux 桌面应用程序使用 OpenID Connect 来对我的用户进行身份验证。

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

因此流程将如下所示:

• native 应用启动并显示登录按钮
• 按下登录按钮时

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

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

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

• native 应用程序从重定向获取代码并关闭端口
• native 应用程序要求 token 端点使用代码获取身份 token

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

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

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

Answer 1

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

从协议(protocol)的角度来看，PKCE已经具有强制性。新的 RFC ( draft-ietf-oauth-security-topics-12 ) 正在对此进行讨论，该 RFC 即将推出。使用 PKCE，您可以避免将授权代码丢失给最终用户计算机中运行的恶意应用程序。

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

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