我想将OpenID连接用于本机Windows和Linux桌面应用程序来验证我的用户。
如本机应用中的" OAuth 2.0"中所述。第7.3节我想从身份验证服务器打开本地TCP端口，以重定向以获取授权代码。我认为对于适用于Windows和Linux的本机应用程序没有其他选择。
所以流就像：
- 本机应用启动并显示登录按钮
- 按下登录按钮
- 本机应用程序打开短暂的本地端口
- 浏览器在身份验证提供商的登录页面上打开(沿客户ID和秘密发送，重定向URI和SCOPE OPENID，RESSSION_TYPE =代码(
- 在浏览器中成功身份验证后
- 验证提供商将重定向URI重定向，即当地开放端口
- 本地端口现在应显示"立即关闭浏览器"之类的内容，然后返回App;向用户
- 本机应用程序从重定向获取代码并关闭端口
- 本机应用程序要求令牌端点使用代码 获得身份令牌
- 使用签名验证身份令牌
- 将能够从该身份令牌中获取用户的详细信息
我现在的问题是我是否需要PKCE？使用URI方案重定向。
我的计划是否有缺陷或需要进一步改进？我知道可以将客户ID和秘密视为"公共"因为他们使用软件运输，并且可以进行逆向工程。但是我的软件将无法在公共网页上(希望(提供，只给予受信任的客户(所有这些都有不同的客户ID和秘密(。
oauth和本机应用程序带来了一些复杂性。这是因为本机应用程序本地运行，而OAuth依靠浏览器来完成流程。首先，我欢迎您查看其他一些问题和答案，其中讨论了与本机应用有关的技术。
。从协议的角度来看，PKCE已成为强制性。这是根据新的RFC(Draft-ietf-Oauth-Security-Topics-12(对此进行了讨论，该公司将很快获得。使用PKCE，您避免将授权代码丢失到最终用户的计算机中运行的恶意应用程序。
原因是，从授权服务器中，它仅依靠客户端ID和重定向URL来识别正确的客户端。因此，如果授权响应被拦截，那么任何一方都可以获取令牌。PKCE通过引入一个安全的随机秘密来避免这种情况，该秘密在运行时生成。这不是存储的，并且只能在SSL保护的令牌请求中进行通信。因此，PKCE减少了窃取令牌的威胁向量。
对于本地应用程序，自定义URL方案的注册是获得授权响应的理想方法。正如规格指出的那样，将其与PKCE结合。
我也有点努力理解桌面流。我建议私人URI计划作为最佳解决方案 - 从这里开始，我有一些跨平台写作，可能会给您一些想法：https://authguidance.com/2018/01/11/desktop-apps-overview/
随意让我有任何后续问题，Gary