【问题标题】:How is Oauth2 protecting the resource owner?Oauth2 如何保护资源所有者?
【发布时间】:2013-10-02 22:53:39
【问题描述】:

过去几个小时我一直在阅读有关 Oauth2 协议的信息。据我了解,该协议的主要动机是资源所有者不必与第 3 方(客户端)应用程序共享其凭据,而只需与资源服务器共享。

在这篇文章中,我使用了Oauth2 RFC 中定义的角色。但是,我并没有区分资源服务器和授权服务器。为了简单起见,我假设它们是相同的,并将它们称为“资源服务器”。

我可以看到两个不同的事件链。假设这两种情况都是从资源所有者开始的,目的是让客户端访问受保护的资源。

案例一,资源服务器提供的GUI

  1. 客户端将资源所有者转发到资源服务器的登录页面。
  2. 资源所有者在资源服务器的 GUI 上提供他/她的凭据。
  3. 成功后,资源服务器将资源所有者转发给客户端,并向用户客户端提供令牌。

案例2,客户提供的GUI

  1. 客户端要求资源所有者向其自己的 GUI 提供他/她的凭据。
  2. 客户端将提供的凭据发送到资源服务器。
  3. 成功后,客户端获取令牌并访问资源服务器。

我关心的是情况 2。如果客户端不是作为客户端进行身份验证,而是作为资源所有者进行身份验证,那么客户端获得资源服务器上的完全权限会有多难? RFC 声明以下是使用 OAuth2 而不是让客户端处理资源所有者凭据的原因:

“第三方应用程序获得了对资源的过于广泛的访问权限 所有者的受保护资源,使资源所有者没有任何 限制持续时间或访问有限子集的能力 资源。”

RFC 进一步指出:

"需要第三方应用程序来存储资源 所有者的凭据以供将来使用,通常是密码 明文。”

这很可能在情况 2 中由客户端保存。

那么...您能假设实现 Oauth2(情况 2)的客户端比没有实现的客户端更安全吗?资源服务器是否有可能实现防止此类事情发生的机制?

【问题讨论】:

    标签: oauth-2.0 oauth2client


    【解决方案1】:

    考虑案例2:

    假设资源所有者已向客户端提供了他/她的凭据,并且正如您所说,客户端必须以纯文本形式将密码存储在某处。

    1) 但是我们可以相信客户不会在未经您许可的情况下访问任何信息吗??
    2) 如果有人入侵客户端数据库并获得所有可能包含敏感信息(如网上银行密码等)的凭据的访问权限,该怎么办??

    所以为了防止这些安全问题,资源所有者直接与资源服务器打交道,并设置客户端只访问它想要的信息而不是更多信息的权限。然后服务器向客户端发出一个令牌(如网关通行证),每当客户端需要一些信息时,它就必须发送令牌。

    因此出于安全原因,最好不要向客户提供我们的凭据。

    【讨论】:

      【解决方案2】:

      您可以假设使用适当的 OAuth2 实现,您的系统比传统的基于用户/密码的系统更安全。

      案例 1 显然更胜一筹,因为没有用户凭据暴露给客户端。

      情况 2 只是一种可能性,许多 OAuth2 提供商根本不支持它。即使标准不鼓励使用它,它似乎只是作为一种后备,当出于某种奇怪的原因仍然必须使用基于普通旧用户/通行证的逻辑时。这种情况仍然稍微好一些,因为客户端应用程序可能根本不存储您的凭据。可以在创建 OAuth 请求后立即删除指定的凭据,并且只应存储授予的令牌。获得刷新令牌,无需再次询问您的用户/通行证。

      请注意,从应用程序中窃取令牌仍然存在安全风险,但窃贼不会对您的凭据拥有完全权限,只会拥有您授予应用程序的访问权限。此外,访问令牌过期,提供者应支持撤销刷新令牌。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2017-08-18
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2019-09-04
        • 2020-11-30
        • 2018-12-11
        • 1970-01-01
        相关资源
        最近更新 更多