我似乎不清楚"资源所有者密码流"one_answers"客户端凭据流"之间的区别。前者似乎将密码凭据转发给服务器进行验证，而后者也以某种方式与服务器进行身份验证，但规范没有指定此处使用的方法。这个流程是为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的第三方应用程序。我想，如果应用程序提示你输入用户名/密码，而不是使用客户端凭据流UI，你(和大多数人)会非常怀疑。
FWIW，这并不是说第一方应用程序不使用客户端凭据流。而是尝试绘制一个真实世界场景(以及总体概括)，说明何时使用资源所有者密码流。
除了用户3287829的答案。我想补充以下内容。
正如RFC所说的客户端凭据授予。
客户端通过使用"；application/x-www-form-urlencoded">
按照附录B的格式，HTTP中的字符编码为UTF-8
请求实体主体：grant_type必需。值必须设置为"0"；客户_凭证"；。
范围可选。访问请求的范围，如第3.3节。
客户端必须按照第3.2.1节中所述的
向授权服务器进行身份验证。例如，客户端使用
传输层安全性(带有额外的换行符用于显示)发出以下HTTP请求仅)：POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=client_credentials授权服务器必须对客户端进行身份验证。
客户端必须事先在授权服务器中注册。并且CCD_ 1包括将由服务器认证的客户端凭证。
这是最接近这个问题的答案。然而，没有一个答案提供了一个更清晰的例子：
- 当计算机需要访问其在另一台计算机上拥有的资源时，必须使用客户端凭据授予
- 当机器需要代表最终用户(而不是机器)访问资源时，有必要使用资源所有者密码凭据授予(实际上不是，最好使用授权代码授予)
在这两个流之间进行选择时，您应该问自己的关键问题是谁拥有要访问的资源。如果它属于机器(客户端)，则需要第一个选项；如果它不属于机器，而是属于机器将代表其执行请求的用户，则需要第二个选项。
其他答案很好地解释了"资源所有者密码流"。因此，我将解释"Client_credentials"授予类型流。在"Client_credentials"流中，Client_id和Client_secret用于验证客户端，而不是资源所有者。因此，您可以在没有资源所有者身份验证的情况下询问客户端(大多数情况下是应用程序)将如何访问资源。这是个好问题。答案是，在这里，客户端将获得其自己的资源的access_token，或者访问已经在此Client_id下提供的用户资源。client_secret和client_id的生成在大多数情况下都是手动过程。例如，看看这个->为GoogleAPI创建客户端ID和客户端机密。在客户端密钥创建步骤中，您将为应用程序创建身份验证凭据。
此外，在审计方面，资源所有者是更好的方式，因为您可以通过access_token识别哪个特定用户正在通过客户端应用程序调用您的api，而client_credential只识别应用程序客户端