【问题标题】:OAuth authentication client side security issuesOAuth 身份验证客户端安全问题
【发布时间】:2015-01-12 12:11:21
【问题描述】:

从提供商的角度,我了解尝试使用 OAuth 进行身份验证的安全问题。但是,我被要求为用户提供使用 OAuth 登录到新 Web 应用程序的工具,并从 Google 和 Twitter 等网站获取他们的基本身份信息,然后在客户端应用程序中创建一个新的用户帐户。此外,对于不希望使用第三方帐户的任何人,用户都可以通过用户/密码直接注册/登录。

我们不需要访问用户的详细信息/信息或提供商 API,只需要他们首次登录时的基本身份,当然还允许他们将来通过提供商登录。不完全是 OAuth 的用例,OpenId 本来是首选,但 OAuth 已经指定,没有有效的问题需要遵守。

我的问题是,假设用户已通过相关提供商正确验证了自己的身份有多安全。如果我相信谷歌能够执行足够的身份验证并且我获得了访问令牌及其身份,那么我大概可以认为这是一个合法用户吗?如果有人可以访问资源所有者的机器并在浏览器中保存密码,则显然存在问题,但对于那些选择直接注册的用户来说,这个问题就存在了。

大概可以伪造访问令牌,例如中间的人假装是谷歌? MITM 可以伪造访问令牌并提供与注册用户的 google id 匹配的身份详细信息?我没有看到任何让客户知道信息肯定来自提供商的东西。显然这个问题并不是 OAuth 独有的。

还有其他方法可以非法访问使用 OAuth 来验证自己的帐户。

【问题讨论】:

  • 首先,访问令牌特定于应用程序而不是最终用户。要获取访问令牌,必须将应用程序注册到服务提供者。其次,OAuth 对用户身份验证过程没有任何参考,提供的用户身份验证只是为了让用户接受应用程序是否可以访问其受保护的资源。那么,如果应用程序本身从未被服务提供商注册过,那么伪造访问令牌如何真正合适呢?
  • 显然应用程序将被注册。我曾认为,如果有东西可以拦截到 OAuth 提供者的通信,他们可以假装是他们,返回一个随机令牌,然后在请求时提供一个捕获的 google id。从未联系过 Google,并且该应用程序“假设”用户已经使用 Google 进行了身份验证。据我所知,客户无法验证令牌来自 Google。

标签: security authentication oauth


【解决方案1】:

OAuth 允许 应用程序 访问 特定 用户资源(已由用户提供权限)并且它不能外出那个范围。我还没有看到有关使用基于 OAuth 的应用程序创建新用户的文档。

话虽如此:

我们不需要访问用户的详细信息/信息或提供者 API,只是他们首次登录时的基本身份

这违反了 OAuth 授权流程。服务提供者进行身份验证并提供相关令牌(基于身份验证的成功)。这是为了确保在 OAuth 身份验证过程中没有进行第 3 方身份验证。

我的问题是假设用户正确 通过相关提供商对自己进行身份验证。

这一切都取决于服务提供商本身。为了符合 OAuth 协议,其中一项要求是用户身份验证必须在具有数字证书的安全传输层中完成(对于 HTTP,必须在 HTTPS 中完成)。 OAuth 消费者对身份验证过程没有任何参考。此外,身份验证过程基本上询问用户消费者是否可以访问特定用户的资源(而不是其他任何人,因为他没有授权)。

是否可以伪造访问令牌,例如中间的男人 冒充谷歌?

欺骗服务提供商是可能的,但它会很乏味。一方面,您必须创建一个完整的 OAuth 握手过程,创建 exact API 作为服务提供者,还必须设置一个安全的环境(如 OAuth 建议的那样)。欺骗服务提供商唯一可以获得的是客户端凭据。如果它有其用户凭据,则无需使用该应用程序,因为无法使用应用程序提供用户凭据来进行恶意破坏。

其次,访问令牌确实会过期,因此即使您欺骗并检索访问令牌,原始应用程序所有者也可以要求服务提供商阻止该应用程序,并且访问令牌可能无用。

一个人在中间攻击是不可能的。您必须在某种意义上复制服务提供商,最终用户将无法区分原始服务提供商和欺骗服务提供商,以便捕获所有相关凭据(来自应用程序和最终用户)。

【讨论】:

  • “我没有看到有关使用基于 OAuth 的应用程序创建新用户的文档。” - 对不起,我不清楚。当用户第一次通过提供者登录时,将提示在客户端应用程序中创建一个新帐户,客户端将为此向提供者请求资源所有者的身份。
  • “这违反了 OAuth 授权过程”,再次不清楚,抱歉。我感谢客户不参与授权,实际上为该项目指定 OAuth 的原因之一是我们持有的信息更少。
  • 谢谢。我是否正确地认为您是在暗示假设提供者的成功响应意味着用户自己进行了有效身份验证是相当安全的?我不担心有人试图访问提供程序中的资源,只是欺骗我们的应用程序。
  • 没有创建帐户。服务提供者将拥有一个“令牌”,知道用户授权了 OAuth 消费者。 OAuth 消费者不知道哪个用户通过了身份验证,也无法将其链接到服务提供者提供的任何令牌。
  • Am I right in thinking that you are implying that it is fairly safe to assume that a successful response from a provider means that the user as validly authenticated themselves? 是的。如果进行了无效的身份验证,服务提供商将向您提供拒绝访问的错误。要欺骗您的应用程序,他们需要读取您的应用程序 ID 和凭据,这意味着他们必须能够解密来自安全传输层的消息或欺骗整个服务提供商。
【解决方案2】:

可悲的是,您最后一句话中的场景是事实。

但是您应该意识到安全性是一个巨大而复杂的问题,尤其是在客户端。它不仅仅发生在一个点上,而是贯穿整个互联网访问生命周期的多个点。您给出的场景不是 OAuth 试图解决的问题。

【讨论】:

  • 是的,我明白安全是一个大问题。登录后始终使用最佳实践,并且应用程序会接受各种安全测试。对于 OAuth,我仅真正关心有人冒充他们并访问该用户的信息,这很重要,但他们无法访问任何高价值资源,这些资源受保护广告。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2012-03-18
  • 2018-06-17
  • 2017-02-08
  • 2013-08-19
  • 2021-05-05
  • 2019-04-07
相关资源
最近更新 更多