为什么我不应该以编程方式向 Facebook/Twitter/Amazon/等提交用户名/密码？
我希望有一个中央、完全可定制、开源、通用的登录系统，允许您登录和管理所有在线帐户（也许有？）...
我刚刚发现 RPXNow 今天开始构建 Sinatra 应用程序来登录 Google、Facebook、Twitter、Amazon、OpenID 和 EventBrite，看起来可能会节省一些时间。
但我一直想知道，我不是身份验证专家，为什么我不能拥有一个时尚的登录页面说“输入用户名和密码，并检查您的登录服务”，然后在后台从 中抓取登录页面EventBrite 并通过 Mechanize 以编程方式提交表单，或者使用 API（如果有）？如果他们不必通过弹出窗口和重定向并且可以使用任何以前存在的帐户，那么它会更加干净，用户体验也会更好。
我的问题是：
- 我不应该做这样的事情的原因是什么？
我对 cookie/会话/安全性的详细细节了解不多，所以如果您能进行描述性的或向我指出一些有用的链接，那就太好了。谢谢！
编辑：
我熟悉 OpenID 和 API。我真的很想知道事情的安全/法律/保密方面。我完全理解保密部分，不知道是否有任何关于此的合法记录，但假设它在 ssl 下，并且我不存储任何数据（将存储 cookie 和令牌），那么安全隐患是什么？
I wish there was a central, fully customizable, open source, universal login system that allowed you to login and manage all of your online accounts (maybe there is?)...
I just found RPXNow today after starting to build a Sinatra app to login to Google, Facebook, Twitter, Amazon, OpenID, and EventBrite, and it looks like it might save some time.
But I keep wondering, not being an authentication guru, why couldn't I just have a sleek login page saying "Enter username and password, and check your login service", and then in the background either scrape the login page from say EventBrite and programmatically submit the form with Mechanize, or use an API if there was one? It would be so much cleaner and such a better user experience if they didn't have to go through popups and redirects and they could use any previously existing accounts.
My question is:
- What are the reasons why I shouldn't do something like that?
I don't know much about the serious details of cookies/sessions/security, so if you could be descriptive or point me to some helpful links that would be awesome. Thanks!
Edit:
I'm familiar with OpenID and the APIs. I was really wondering about the security/legal/confidentiality side of things. I understand the confidentiality part totally, don't know if there's anything legally written down about this, but assuming it's under ssl, and I don't store any of the data (will store the cookies and tokens), what are the security implications?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果我访问您的网站并给您我的 gmail 密码，我如何保证您不会阅读我的所有电子邮件，甚至发送您自己的几封电子邮件？如果你变得聪明一点并说“人们重复使用密码，我不妨尝试一下这个密码是否适用于他的银行帐户”。
作为用户，我不信任您的网站使用我的密码。
Open Id 和 OAuth（这就是 RPX 使用的）的全部意义在于解决上述问题。我可以为您的网站提供对我的 Facebook 帐户的受限、可撤销和可配置的访问权限，而无需向您的网站提供我的 Facebook 密码。
用户界面令人困惑，我同意。但随着时间的推移，人们会理解它的全部内容，而且会好很多。
If I come to your website and give you my gmail password, what guarantee do I have that you won't read all my emails and even send a few of your own? And what if you become a little smarter and say 'people reuse passwords, I might just as well try if this password works for his bank account'.
As a user, I don't trust your site with my password. Period.
The whole point of Open Id and OAuth (that's what RPX uses) is to get around the above issue. I can give your website restricted, revocable and configurable access to my facebook account, all without giving your website my facebook password.
The UI is confusing, I agree. But with time people will understand what its all about, and it will be a lot better.
如上所述：
但我觉得还有其他充分的理由：
许多人在多个网站或帐户上使用相同的密码（有些人可能在 gmail 和 paypal 上使用相同的密码 ），网站所有者可能会滥用这一点
网站所有者不希望为其他网站所有者滥用您的帐户承担责任
网站所有者无法以安全方式存储您的用户名和密码。该网站需要能够自动访问它们。因此，在托管服务器上存储了访问这些凭据所需的所有内容。
托管通常发生在共享或虚拟服务器中，托管公司管理员（有时 - 如果托管公司不太意识到 - 其他用户）能够访问它们。
As already said above:
But I feel there are other good reasons:
Many people use the same password on more than one site ore account (some could have the same password on gmail and paypal) and the site owner could abuse that
The site owner doesn't want to be held liable for other site owners abusing your account
The site owner could not be able to store your username and password in secure fashion. The site needs to be able to access them automatically. So on the server hosting there is stored everything needed to access those credentials.
And the hosting usually happens in a shared or virtual server with the hosting company administrators (and sometimes - if the hosting company isn't too conscious - fellow users) able to access them.
安全和保密。时期。
我相信，甚至像 Facebook 这样的一些网站也不鼓励在他们的服务条款中使用这种方法。如果是这样，这样做将是违法的。
Security and Confidentiality. Period.
Even some websites like Facebook discourage using this approach in their TOS i believe. If so, it will be illegal to do so.