使用twitter凭据作为站点凭据的最佳实践

该任务很简单。我想使用“使用Twitter登录”作为用户的凭据，允许他们访问网站的受限区域并将其操作与其帐户相关联。使用twitter凭据作为站点凭据的最佳实践

我可以在Twitter上签名。我得到一个ID，用户名，oauth标记，秘密标记，...

现在让我们说，用户然后做出特定于网站的行为，如对调查的投票。我想将投票归因于他们的账户。

我应该向服务器发送什么信息来证明投票是来自Twitter用户的投票？

例如，是否足以发回Twitter ID和投票？其他人是否可以获得此ID的保留，然后开始以用户名义进行投票？

我应该向服务器发送Twitter ID，oauth令牌和秘密令牌吗？再次，我如何验证这些凭据是否有效？服务器是否需要在每次特定于站点的操作后向Twitter发出呼叫以验证这些凭据？这似乎过分。

我是否让服务器验证一次凭据，然后发回一些随机会话密钥，然后在每次请求剩余会话后验证会话密钥？

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

而且，我在node.js中和的情况下使用hello.js有一个堆栈特定的解决方案

感谢

来源

2015-02-23 kane

我意识到我的假设存在固有的问题。 hello.js允许我在前端进行身份验证（在第三方代理服务器的帮助下）。因为我的服务器从来没有看到令牌交换，所以它依赖于客户端来告诉它它已经被认证，这是我使用这种方法的地方。取而代之的是，我最终使用了后端认证的passport.js – kane 2015-02-27 07:42:27

你的会话密钥的想法是好的。它将保证进一步请求（例如投票）和Twitter用户ID之间的关联。唯一的问题是，如果存在中间人，则他们捕获会话密钥并可以重播请求。这可以通过使用HTTPS来解决，它保证没有人与传入的请求混淆，从而保证与用户的关联。而且由于会话密钥很短，所以它们不可能用于未来的攻击。

来源

2015-02-23 03:42:17 amahfouz

我提出的会话密钥解决方案中唯一出现的问题是，它导致两个令牌验证，一个在客户端，当用户使用Twitter登录时，以及然后再次在服务器端生成随机会话密钥。想知道是否有更高效的方法 – kane 2015-02-23 07:52:19

好吧，OAuth已经是一个多步骤的过程，所以与额外的安全性的好处相比，这个额外步骤的成本实际上可以忽略不计。 – amahfouz 2015-02-23 19:52:52

不幸的是，一些社交网络对我可以做多少令牌验证有限制。例如Twitter每15分钟限制到15次，所以这不会在生产网站上扩展 – kane 2015-02-27 07:40:50

使用twitter凭据作为站点凭据的最佳实践

回答

相关问题