OAuth 2.0建议不要使用password授权类型，它将在OAuth 2.1更新中被删除。但是，当你有一个机器对机器的通信渠道时，什么是合适的解决方案呢？
在我的例子中，我有两个Powershell脚本，它们可以获取在后续API调用中使用的访问令牌。因此，他们通过提供我的应用程序用户的用户名和密码来请求访问令牌，该应用程序用户有自己的声明，因此可以访问有限的API。
我也可以使用client_credentials流，但这样我就不会对实际的批处理用户进行身份验证，而只是对我的客户端进行身份验证。可能不会给我给予我想要的权利。作为后续问题，硬编码客户端id + secret与硬编码用户+密码有什么不同？
1条答案
按热度按时间zd287kbt1#
client credentials flow是后端启动的流的正确选项，例如在没有用户参与时的计划作业。或者，如果您的脚本由管理员用户交互运行，则脚本可以使用本机代码流，即控制台（本机）客户端。这样做可能会根据脚本用户发出不同的声明。
不管流量如何，您仍然可以使用声明。客户端的
scope触发包含声明。发布声明不一定要涉及用户。例如，考虑一个检查未付发票的夜间工作。这可以使用一个像
invoices:reconcile这样的作用域，它不被任何其他客户端使用。使用此范围还可能触发包含声明，例如region=USA，其中声明是基于令牌发行时应用的某些逻辑计算的。某些授权服务器可能对如何为客户端凭据流发出声明有限制，这意味着您可能需要采取变通办法。但是OAuth 2.0本身没有这样的限制，所以我总是鼓励大多数基于标准的设计。
客户端凭据流
对于客户端凭据流，可以使用这些方法之一，该方法支持多个调用方，但只需要一个客户端注册。根据收到的财产，可以提出不同的索赔要求：
通常建议单独的客户。它可以确保，如果客户端A的凭据被泄露，您可以拒绝访问而不会影响客户端B。