【问题标题】:OAuth Redirect URLOAuth 重定向 URL
【发布时间】:2015-08-28 17:50:34
【问题描述】:

在 OAuth 2 中,当您添加客户端时,您会给它一个重定向 url。

例如

http://example.com

但是当您为用户请求授权时,您还会将重定向 url 作为请求的一部分传回。

例如

authorize?response_type=code&client_id=CLIENT_ID&return_url=http%3A%2F%2Fexample.com%2Fsecure%2F&state=STATE

我的问题基本上是,针对客户端存储重定向 url 有什么意义?这只是为了确保您只重定向到原始网站而不是作为请求的一部分传递的任何内容吗?

在任何情况下,我发现作为请求的一部分发送的返回 url 参数不被遵守,例如http://example.com/secure 并且始终使用针对客户端保存的重定向 url...因此您不会被重定向到原始请求,而只会被重定向到主页。

应该发生什么?为什么我们有两次返回 url?

不应该只是针对客户端存储的域,然后使用传回的返回 url,然后比较域的安全性吗?

【问题讨论】:

    标签: oauth oauth-2.0


    【解决方案1】:

    这确实是一种安全措施,因此响应仅发送到在注册/管理时已明确与客户端关联的 URL。

    客户端可以注册多个重定向 URI,在这种情况下,在请求中使用 redirect_uri 查询参数来指示服务器需要向哪个注册值发送响应很有用。如果注册值只有一个,可以在请求中省略redirect_uri查询参数。

    此机制可防止网络钓鱼攻击,在这种攻击中,攻击者诱骗用户单击包含精心制作的 redirect_uri 参数的链接,该参数指向攻击者控制的域/服务器。

    规范确实允许注册可用于匹配请求中的redirect_uri 值的模式,例如可以配置域范围的策略。这是一个特定于实现的选项。请注意,在这种情况下,您需要确保域上的所有可能的 URL/路径实际上是由客户端所有者而不是其他人控制的(例如,排除从外国域加载内容的页面,或者潜在危险的维基/论坛页面)。由于这在现实生活中相当困难,因此推荐/默认匹配非常严格。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2021-04-19
      • 2017-02-26
      • 1970-01-01
      • 2023-04-05
      • 1970-01-01
      • 2020-01-21
      • 2021-04-16
      • 2020-11-24
      相关资源
      最近更新 更多