【问题标题】:Best Practice for using twitter credentials as site credentials使用 twitter 凭据作为站点凭据的最佳实践
【发布时间】:2015-02-23 11:42:17
【问题描述】:

任务很简单。我想使用通过 Twitter 登录作为用户的凭据,允许他们访问网站的受限区域并将他们的操作与他们的帐户相关联。

我可以通过 Twitter 让他们登录。我得到了一个 id、用户名、oauth 令牌、秘密令牌……

现在假设用户执行了特定于站点的操作,例如对调查进行投票。我想将投票归功于他们的帐户。

我应该向服务器发送什么来证明投票来自它所说的 twitter 用户?

例如,发回 twitter id 和投票就足够了吗? 其他人可以拿到这个id,然后代表用户开始投票吗?

我应该将 twitter id、oauth 令牌和秘密令牌发送到我的服务器吗? 同样,我如何验证这些凭据是否有效?服务器是否需要在每次特定于站点的操作后调用 twitter 来验证这些凭据?这似乎太过分了。

我是否让服务器验证一次凭据并发送回一些随机会话密钥,然后在会话剩余部分的每个请求后验证会话密钥?

这种事情已经在数千个网站上实施,所以只是想知道这个常识性的解决方案是什么。对不起,如果这个问题以前被问过。在这种情况下,将不胜感激参考答案。

另外,我正在使用 node.js 并使用 hello.js,以防有特定于堆栈的解决方案

谢谢

【问题讨论】:

  • 我意识到我的假设存在固有问题。 hello.js 允许我在前端进行所有身份验证(在 3rd 方代理服务器的帮助下)。因为我的服务器从来没有看到令牌交换,它依赖客户端告诉它它已经过身份验证,这是我对这种方法感到厌烦的地方。相反,我最终使用了作为后端身份验证的 passport.js

标签: authentication twitter oauth


【解决方案1】:

您的会话关键点子很好。它将保证进一步请求(例如投票)和 Twitter 用户 ID 之间的关联。唯一的问题是如果有中间人,那么他们会捕获会话密钥并可以重播请求。这是通过使用 HTTPS 解决的,它保证没有人干扰传入的请求,从而保证与用户的关联。而且由于会话密钥是短暂的,因此不可能在未来的攻击中使用它们。

【讨论】:

  • 我提出的会话密钥解决方案的唯一问题是,它会导致两次令牌验证,一个在用户使用 Twitter 登录时在客户端,然后在服务器端再次验证生成随机会话密钥。想知道是否有更有效的方法
  • 嗯,OAuth 已经是一个多步骤的过程,因此与增加安全性的好处相比,这个额外步骤的成本真的可以忽略不计。
  • 不幸的是,一些社交网络对我可以进行的令牌验证数量有限制。例如Twitter 每 15 分钟限制为 15 个,因此无法在生产站点上扩展
猜你喜欢
  • 2010-10-27
  • 2015-03-06
  • 2011-12-10
  • 1970-01-01
  • 1970-01-01
  • 2010-10-05
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多