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

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

This 是最接近该问题的答案。但是，没有一个答案提供了更清晰的例子：

1. 当一台机器需要访问它在另一台机器上拥有的资源时，您必须使用客户端凭据授权。
2. 当机器需要访问属于最终用户（不是机器）的资源时，需要使用Resource Owner Password Credentials Grant（实际上没有，最好使用Authorization Code Grant） 代表该用户。

在这两个流程之间进行选择时，您应该问自己的关键问题是谁拥有要访问的资源。如果它属于机器（客户端），那么你需要第一个选项，如果它不属于机器，但属于机器将代表其执行请求的用户，那么你需要第二个选项。

Answer 2

其他答案很好地解释了“资源所有者密码流程”。所以我将解释“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。在客户端密码创建步骤中，您正在为您的应用程序创建身份验证凭据。

Answer 3

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

客户端凭据流允许应用程序在不考虑用户上下文的情况下获取令牌。

Answer 4

一个很好的例子如下：

假设您是一家名为 AllStats 的统计公司，拥有自己的用户群，其中每个用户都有自己的用户名和密码。 AllStats 拥有自己的现有网站，其中包含自己的 API。然而，AllStats 现在想要发布一个移动应用程序。

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

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

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

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

FWIW，这并不是说第一方应用不使用客户端凭据流。而是尝试描绘何时使用资源所有者密码流的真实场景（和总体概括）。

Answer 5

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

正如RFC 所说的关于客户端凭据授予。

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

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 6

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