“资源所有者密码流程”和“客户凭证流程”之间的区别
“资源所有者密码流程”和“客户凭证流程”之间的区别对我来说似乎不清楚。前者似乎将密码凭据转发给服务器进行验证，而后者也以某种方式与服务器进行身份验证，但规范没有指定这里使用什么方法。这个流程是为 cookie 会话设计的吗？该规范并没有真正提供明确的用例。
从 OAuth 2.0 规范：
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
Figure 6: Client Credentials Flow
和
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
Figure 5: Resource Owner Password Credentials Flow
客户端凭据流仅需要 client_id 和 client_secret。资源所有者流程需要用户密码。
客户端凭据流允许应用程序在不考虑用户上下文的情况下获取令牌。
一个很好的例子如下：
假设您是一家名为 AllStats 的统计公司，拥有自己的用户群，其中每个用户都有自己的用户名和密码。 AllStats 拥有自己的现有网站，其中包含自己的 API。然而，AllStats 现在想要发布一个移动应用程序。
由于移动应用程序将是第一方应用程序（参见：由 AllStats 开发），因此资源所有者密码流非常有意义。您将希望用户获得与应用程序一起流动的屏幕（用户名、密码），而不是将它们踢到身份验证服务器（然后返回应用程序）。用户在输入用户名/密码时会信任该应用程序，因为它是第一方应用程序。
我喜欢将资源所有者密码流程视为第一方应用程序开发人员将使用的流程，而将客户端凭据流程视为第三方应用程序开发人员将使用的流程。
想象一下，如果 Facebook 应用程序要求您使用客户端凭据流，而不仅仅是向您提供用户名/密码表单。看起来有点奇怪，是吗？
现在，假设您下载了一个集成了 Facebook 的 3rd 方应用程序。如果应用程序提示您输入用户名/密码而不是使用客户端凭据流 UI，我想您（和大多数人）会非常谨慎。
FWIW，这并不是说第一方应用程序不使用客户端凭据流。而是尝试描绘何时使用资源所有者密码流的真实世界场景（和整体概括）。
Client Credential Flow UI
除了user3287829的回答。我想添加以下内容。
正如 RFC 所说，授予客户凭据。
客户端通过使用附录 B 中的“application/x-www-form-urlencoded”格式添加以下参数向令牌端点发出请求，HTTP 请求实体主体中的字符编码为 UTF-8：grant_type REQUIRED。值必须设置为“client_credentials”。范围可选。访问请求的范围如第 3.3 节所述。客户端必须向授权服务器进行身份验证，如第 3.2.1 节所述。例如，客户端使用传输层安全性发出以下 HTTP 请求（额外的换行符仅用于显示目的）： POST /token HTTP/1.1 主机：server.example.com 授权：基本 czZCaGRSa3F0MzpnWDFmQmF0M2JW 内容类型：application/x -www-form-urlencoded grant_type=client_credentials 授权服务器必须对客户端进行身份验证。
客户端必须提前在授权服务器中注册。 Authorization 包括将由服务器进行身份验证的客户端凭据。
This 是最接近该问题的答案。但是，没有一个答案提供了更清晰的示例：
当一台机器需要访问它在另一台机器上拥有的资源时，您必须使用 Client Credentials Grant。当机器需要代表该用户访问属于最终用户（不是机器）的资源时，需要使用 Resource Owner Password Credentials Grant（实际上不需要，最好使用 Authorization Code Grant）。
在这两个流程之间进行选择时，您应该问自己的关键问题是谁拥有要访问的资源。如果它属于机器（客户端），那么你需要第一个选项，如果它不属于机器，但属于机器将代表其执行请求的用户，那么你需要第二个选项。
其他答案很好地解释了“资源所有者密码流程”。所以我将解释“Client_credentials”授权类型流程。在“Client_credentials”流程中，client_id 和 client_secret 用于验证 Client 而不是 Resource owner。因此，您可以在没有资源所有者身份验证的情况下询问客户端（大多数情况下是应用程序）如何获得对资源的访问权限。这是个好问题。答案是，这里客户端将获得 access_token 以获得它自己的资源或访问已在此 client_id 下提供的用户资源。 client_secret 和 client_id 生成大部分时间是手动过程。例如看看这个 -> Create a client ID and client secret for google APIs。在客户端密码创建步骤中，您正在为您的应用程序创建身份验证凭据。
此外，在审计方面，资源所有者是更好的方法，因为您可以通过 access_token 识别哪个特定用户正在通过客户端应用程序调用您的 api，而 client_credential 仅识别应用程序客户端
