【问题标题】:OAuth2 without Client Secret – Possible Phishing?没有客户端密码的 OAuth2 – 可能的网络钓鱼?
【发布时间】:2017-11-19 14:15:07
【问题描述】:

我一遍又一遍地阅读 OAuth2 规范,但我无法弄清楚一件事。没有客户端密码的授权代码流(现在推荐用于单页应用程序)是否非常不安全,因为它很容易被用于网络钓鱼?让我解释一下:

  1. 客户端将资源所有者重定向到授权服务器,并传递重定向 URL 和客户端 ID。
  2. 资源所有者批准请求,授权服务器将他重定向到给定的重定向 URL 并传递授权代码。

现在,实际上,请求授权的客户端是一个钓鱼网站,很遗憾,用户没有识别该网站。传递给授权服务器的重定向 URL 指向恶意客户端,而不是合法客户端。客户 ID 是公开信息,因此设置此类站点相当容易。

如果需要客户端密码会怎样?

  1. 恶意客户端会收到授权码,但不知道合法的客户端密钥。
  2. 资源服务器将拒绝发送访问令牌,因为未提供有效的客户端密码。用户信息是安全的。

但是如果资源服务器不需要客户端密码呢?

  1. 恶意Client会收到授权码,即使不知道Client Secret,也会请求Access Token。
  2. 资源服务器将接受请求,因为提供了有效的授权代码和客户端 ID,并且不需要客户端密码。恶意Client获取Access Token,用户信息泄露。

我是否遗漏了什么或者这是否正确,并且没有什么可以使 OAuth2 与单页应用程序一起使用更安全?

【问题讨论】:

  • 此外,SPA 上的客户端密码也不安全,每个人都可以复制它,而且众所周知,错误使用密码可能会导致拥有 2 倍于服务器之间和服务器之间安全通信的相同密码同时它为 SPA 向所有人公开,这也是为什么不建议将客户端密码用于 SPA

标签: javascript security oauth single-page-application


【解决方案1】:

资源服务器不需要client_secret,因为只有有效的客户端才能获得兑换授权码。

必须不仅针对client_id 验证客户端,还必须针对注册到客户端的redirect_uri 验证客户端。注册 OAuth 客户端时,您应该需要一个允许与 client_id 一起使用的重定向 uri 列表。

因此,如果恶意客户端发出请求,它将无法通过验证,因为您必须仅在允许 redirect_uri 时重定向。

这在 OAuth 2.0 RFC 的 3.1.2.2 https://www.rfc-editor.org/rfc/rfc6749#section-3.1.2.2 部分中有详细说明

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2017-11-27
    • 2011-03-02
    • 2014-12-27
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-01-16
    相关资源
    最近更新 更多