受信任桌面客户端的客户端凭证流或授权代码流（使用 PCKE）
Client Credentials Flow or Authorization Code Flow (with PCKE) for a trusted desktop client
我正在为几个 API 开发 authentication/authorization 架构。
我正在使用 IdentityServer4 作为安全令牌服务 (STS)。
根据我从 "Dominick Baier"（构建 IdentitySever4 的人之一）那里读到的内容，只有两种类型的流应该被使用：
- 客户端凭据流。 （机器对机器）
- 授权代码流 + PCKE。 （对于迭代用户）。
我有几个 C# Web API 将与每个（机器对机器）通信，我将使用客户端凭据流。
但是有一些 WPF 桌面应用程序需要访问一些 API，并且没有用户。
应该使用哪个流程？
我读过：
Desktop/Native 和移动应用程序应使用授权代码流授权（使用 Public 客户端和 PKCE），因为它们托管在客户端，并且 Client/Secret 可能会泄露（可能在一个桌面应用程序，我们可以加密秘密？但是接下来需要管理一种方法来存储解密的秘密吗？）
然后我读到：
"Anytime you have a system that isn’t concerned with the end-user identity (and just needs to authenticate the system), use the OAuth2 Client Credential Grant."
目前，这是我的情况，我不关心最终用户身份（但也许在不久的将来我会）。
所以由于以上几点相互冲突：
- 我应该使用哪个流程？
- 我可以拥有一个使用客户端凭据流的桌面客户端并且安全吗？
此外，我已经阅读了一些有关相互 TLS 的内容，如果我使用它，这会改变我应该使用的流程吗？
您不能信任客户端，因为您不能确定请求来自客户端。另一个问题是客户不善于保守秘密。但是有不同类型的客户。
服务器上 运行 的客户端通常具有单一任务，例如同步独立于用户的数据，适合使用客户端凭据流。在某种程度上，他们可以保守秘密（运行在服务器上）。
您可以为每个实例使用唯一的凭据，但这并不能使它更安全。它可以帮助您识别客户端，但不会增加安全性。安全是关于监视行为和检测异常。或者通过过滤 IP 地址来缩小访问范围。
但您不限于使用您提到的两个流程。作为令牌提供者，您可以使用 extension grants.
通过自定义流程扩展 IdentityServer
在没有用户的情况下，客户端凭据有点类似于资源所有者密码凭据 (ROPC) 流程（授权类型文档中不再涵盖但仍然存在的另一个选项，请参阅 old docs）。从两者都可以自动化的意义上说，它们都不是真正安全的。可以消除用户因素，因为这些流程不需要用户交互。
但我想知道为什么您的应用程序没有用户，运行在用户计算机上。因为理想情况下，您有一个客户端（没有秘密），用户可以在其中登录并让客户端联系 api (delegation).
所以有两件事：你需要识别客户吗？如果没有，您可以使用 ApiKey 来满足需求，例如发送网格。而且您永远无法信任客户。安全必须是服务器端。
所以基本上这并不重要，您无法做任何事情来使客户端更安全。您唯一可以做的就是添加用户交互的要求。所以也许现在您不需要它，但它会提高安全性并允许您将 api 访问权限委托给客户端。
我正在为几个 API 开发 authentication/authorization 架构。
我正在使用 IdentityServer4 作为安全令牌服务 (STS)。
根据我从 "Dominick Baier"（构建 IdentitySever4 的人之一）那里读到的内容，只有两种类型的流应该被使用：
- 客户端凭据流。 （机器对机器）
- 授权代码流 + PCKE。 （对于迭代用户）。
我有几个 C# Web API 将与每个（机器对机器）通信，我将使用客户端凭据流。
但是有一些 WPF 桌面应用程序需要访问一些 API，并且没有用户。 应该使用哪个流程？
我读过： Desktop/Native 和移动应用程序应使用授权代码流授权（使用 Public 客户端和 PKCE），因为它们托管在客户端，并且 Client/Secret 可能会泄露（可能在一个桌面应用程序，我们可以加密秘密？但是接下来需要管理一种方法来存储解密的秘密吗？）
然后我读到： "Anytime you have a system that isn’t concerned with the end-user identity (and just needs to authenticate the system), use the OAuth2 Client Credential Grant."
目前，这是我的情况，我不关心最终用户身份（但也许在不久的将来我会）。
所以由于以上几点相互冲突： - 我应该使用哪个流程？ - 我可以拥有一个使用客户端凭据流的桌面客户端并且安全吗？
此外，我已经阅读了一些有关相互 TLS 的内容，如果我使用它，这会改变我应该使用的流程吗？
您不能信任客户端，因为您不能确定请求来自客户端。另一个问题是客户不善于保守秘密。但是有不同类型的客户。
服务器上 运行 的客户端通常具有单一任务，例如同步独立于用户的数据，适合使用客户端凭据流。在某种程度上，他们可以保守秘密（运行在服务器上）。
您可以为每个实例使用唯一的凭据，但这并不能使它更安全。它可以帮助您识别客户端，但不会增加安全性。安全是关于监视行为和检测异常。或者通过过滤 IP 地址来缩小访问范围。
但您不限于使用您提到的两个流程。作为令牌提供者，您可以使用 extension grants.
通过自定义流程扩展 IdentityServer在没有用户的情况下，客户端凭据有点类似于资源所有者密码凭据 (ROPC) 流程（授权类型文档中不再涵盖但仍然存在的另一个选项，请参阅 old docs）。从两者都可以自动化的意义上说，它们都不是真正安全的。可以消除用户因素，因为这些流程不需要用户交互。
但我想知道为什么您的应用程序没有用户，运行在用户计算机上。因为理想情况下，您有一个客户端（没有秘密），用户可以在其中登录并让客户端联系 api (delegation).
所以有两件事：你需要识别客户吗？如果没有，您可以使用 ApiKey 来满足需求，例如发送网格。而且您永远无法信任客户。安全必须是服务器端。
所以基本上这并不重要，您无法做任何事情来使客户端更安全。您唯一可以做的就是添加用户交互的要求。所以也许现在您不需要它，但它会提高安全性并允许您将 api 访问权限委托给客户端。