【问题标题】:OAuth2 : redirect_uri post LinkedIn & FacebookOAuth2:redirect_uri 发布 LinkedIn 和 Facebook
【发布时间】:2015-04-24 11:45:02
【问题描述】:

我正在执行服务器端 oAuth2 流程。

我注意到 google 为他们的 oAuth2 登录 API 添加了一个很酷的功能,即 redirect_uri=postmessage,因此我们不会在浏览器 url 栏上显示真正的 redirect_uri,authorization code 不会包含在重定向 url 中.

对于linkedin,当用户同意与应用分享他的个人数据时,响应网址如下:

http://dev.localhost.com:8080/auth/linkedin?code=xxxxxxxxxxx&state=yyyyyyyyyyyyy

Google 是一样的,除非我们用postmessage 替换真正的redirect_uri。

如果在 url 中设置了 redirect_uri + 响应代码,每个恶意脚本都可以从 url 中检索返回的code 并执行自己的身份验证。

那么,有什么方法可以隐藏 LinkedIn 和 Facebook 的返回参数和 redirect_uri 吗?

【问题讨论】:

  • “每个恶意脚本都可以从 url 检索返回的代码并执行自己的身份验证” - 不,他们不能,因为将 code 交换为访问令牌需要您的应用程序密码。 (如果您将其暴露于 3rd 方脚本,那么您已经遇到了更大的问题。)
  • 我明白了。这澄清了事情,谢谢。

标签: facebook oauth-2.0 google-plus linkedin


【解决方案1】:

LinkedIn 和 Facebook 不易受到访问 redirect_uri 的恶意脚本的攻击。

假设您使用推荐的response_type=code,这两个 API 都需要您从服务器发出请求,其中包含您的 API 密钥和 code 值,以便获取用户令牌。 LinkedIn 在Exchange Authorization Code for a Request Token 中对此进行了描述,Facebook 在Exchanging code for an access token 中对此进行了描述。

要求every request be signed with your API secret 可以启用 Facebook 的额外安全性。通常可以通过使用强大的Content Security Policy 来获得额外的保护,以帮助防止恶意脚本首先运行。并确保您的网站仅通过 TLS 托管,以防止您自己的 JavaScript 被修改。

【讨论】:

  • 我明白,这很有启发性。谢谢!
猜你喜欢
  • 2020-12-29
  • 1970-01-01
  • 2015-02-16
  • 1970-01-01
  • 1970-01-01
  • 2013-03-21
  • 2014-10-25
  • 2016-03-12
  • 1970-01-01
相关资源
最近更新 更多