首页 文章

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

提问于
浏览 次
48

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

4 回答

  • 22

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

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

    回复于
  • 0

    一个很好的例子如下：

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

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

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

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

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

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

    回复于
  • 2

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

    正如RFC所说的客户资格补助金 .

    客户端通过使用附录B中的“application / x-www-form-urlencoded”格式添加以下参数来向令牌 endpoints 发出请求，其中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 包括将由服务器验证的客户端凭证 .

    回复于
  • 37

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

    回复于

相关问题