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

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集成的第三方应用程序.如果应用程序提示您输入用户名/密码而不是使用Client Credential Flow UI,我想你(以及大多数人)会非常谨慎.

FWIW,这并不是说第一方应用程序不使用客户端凭据流.而是尝试绘制资源所有者密码流何时使用的真实场景(以及整体概括).