Question

“资源所有者密码流”和“客户端凭据流”之间的区别对我来说似乎不太清楚。前者似乎将密码凭证转发给服务器进行验证，而后者也以某种方式对服务器进行身份验证，但规范没有指定此处使用的方法。此流程是否适用于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

Answer 1

客户端凭据流仅需要client_id和client_secret。资源所有者流程需要用户的密码。

客户端凭据流允许应用程序从用户的上下文中获取令牌。

Answer 2

这方面的一个很好的例子如下：

假设您是一家名为AllStats的统计公司，它拥有自己的用户群，每个用户都有自己的用户名和密码。 AllStats拥有自己的现有网站，可以自己动手制作API。但是，AllStats现在想要发布移动应用程序。

由于移动应用程序将是第一方应用程序（请参阅：由AllStats开发），因此资源所有者密码流非常有意义。您希望用户获得与应用程序一起流动的屏幕（用户名，密码），而不是将其踢到auth服务器（然后返回应用程序）。用户在输入用户名/密码时会信任该应用程序，因为它是第一方应用程序。

我喜欢将资源所有者密码流视为第一方应用开发者将使用的流，而客户端凭据流则是第三方应用开发者将使用的流。

想象一下，如果Facebook应用程序要求您使用客户端凭据流而不是仅向您显示用户名/密码表单。看起来有点奇怪，是吗？

现在，如果想象你下载了一个有Facebook集成的第三方应用程序。如果应用程序提示您输入用户名/密码而不是使用客户端凭据流UI，我会想象您（以及大多数人）会非常谨慎。

FWIW，这并不是说第一方应用程序不使用客户端凭证流程。而是尝试绘制使用资源所有者密码流时的真实场景（以及整体概括）。

Answer 3

除了user3287829的答案。我想添加以下内容。

正如RFC所说的客户资格授予。

客户端通过添加
向令牌端点发出请求   以下参数使用“application / x-www-form-urlencoded”
  格式为附录B，HTTP中的字符编码为UTF-8   请求entity-body：

grant_type            需要。值必须设置为“client_credentials”。

范围            可选的。访问请求的范围如下所述            第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
授权服务器必须验证客户端。

客户端必须事先在授权服务器中注册。并且Authorization包括将由服务器验证的客户端凭证。

Answer 4

另外，在审计方面，资源所有者是更好的方法，因为你可以通过access_token识别哪个特定用户通过客户端应用程序调用你的api，而client_credential只识别应用程序客户端

Answer 5

其他答案很好地说明了“资源所有者密码流”。因此，我将解释“ Client_credentials”授予类型流程。在“ Client_credentials”流中， client_id 和 client_secret 用于认证 Client ，而不是资源所有者。因此，您可以在没有资源所有者身份验证的情况下询问客户端（大多数情况下是应用程序）如何获得对资源的访问权限。这是个好问题。答案是，在这里，客户端将获得 access_token ，因为它是其自身的资源或对已在此 client_id 下给出的用户资源的访问。大多数情况下，client_secret和client_id的生成是手动过程。例如，查看此-> Create a client ID and client secret for google APIs。在“客户端机密创建”步骤中，您正在为应用程序创建身份验证凭据。

“资源所有者密码流”和“客户端凭据流”之间的区别

5 个答案: