OpenID：为什么在 cookie 中存储声明的 ID 是安全的？
我刚刚开始在我的网站中集成 OpenID。我看到的所有示例都将声明的 ID 存储在 cookie 中。如何安全？
例如，myopenid.com 返回的已声明 ID 为 {username}.myopenid.com
因此，如果黑客知道您已声明的 ID，他就可以轻松破解您的帐户。
当然，您在将 ID 放入 cookie 并用于身份验证之前对其进行加密/md5，但这就像存储没有密码的用户名一样！
更新
现在我想得更多了，我意识到，你需要登录OpenID提供商，所以即使黑客获得了用户名，他仍然需要提供商的密码才能登录。Am我说得对吗？
更新2 不，更新 1 不正确:) 我的网站无法检查用户是否成功登录。我收到的只是所声明的 ID，我只需相信用户已通过身份验证。这真是令人困惑...
I just started integration of OpenID in my website. All the examples I saw store the claimed IDs in cookies. How is it safe?
For example, myopenid.com returns a claimed ID that is {username}.myopenid.com
So if a hacker knows your claimed ID, he can easily hack your account.
Of course you encipher/md5 the ID before putting it into the cookies and using for authentication, but it's like storing a username without password!
Update
Now that I thought more about it, I realized, that you need to be logged in the OpenID provider, so even if the hacker gets the username, he still needs the provider's password to log in. Am I correct?
Update 2
No, update 1 is not correct :) My site cannot check whether the user is successfully logged in or not. All I receive is the claimed ID, and I just have to trust that the user is authenticated. That's really confusing...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
知道用户声称的身份不足以进行身份验证。
事实上，用户必须登录其提供商，才能使用该身份向您的网站进行身份验证。
至于“相信用户已经过身份验证”——不，你不信任。作为 OpenID 身份验证的最后一部分，您应该验证身份验证消息是否来自提供商。有各种安全措施来确保消息是真实的、未被更改的等。
如果您这样做，您就可以确定您的用户已通过提供商的正确身份验证。
现在，由于您不想每次用户发出请求时都执行此操作，因此您将会话信息存储在 cookie 中。然而，您不仅仅存储所声明的标识符（如果您决定存储它），而是存储一个会话 ID——用户登录时生成的一个伪随机数。由于它是伪随机的，所以没人能猜到它，因此，了解所声明的标识符本身并没有任何意义。
如果这回答了您的问题，请阅读您最喜欢的语言/框架中的会话管理，因为它将告诉您如何轻松实现这种机制及其工作原理。
总之：将 OpenID 视为密码验证的替代品。您不需要（也不应该）在 cookie 中存储登录名和密码，也不必存储声明的标识符。同样，您不必每次都验证登录名和密码是否匹配，但请记住用户在会话中进行了身份验证。
Knowing the user's claimed identity isn't enough to authenticate.
Indeed, the user would have to be logged in to his provider, in order to authenticate with your website using that identity.
As for "trusting that the user is authenticated" -- no, you don't trust. As a final part of OpenID authentication you're supposed to verify that the authentication message comes from the provider. There are various security measures in place to ensure that the message is authentic, unaltered, etc.
If you do that, you're sure that your user is properly authenticated by the provider.
Now, since you don't want to do it every time your user makes a request, you store the session information in a cookie. However, you don't store only the claimed identifier (if you decide to store it at all), but a session id -- a pseudorandom number generated at the moment your user logs in. Since it's pseudorandom, no one can guess it, and therefore, knowledge of a claimed identifier itself doesn't mean anything.
If that answers your question, read about session management in your favorite language/framework, as it will tell you how to easily implement such mechanism, and how it works.
In summary: think of OpenID as a replacement for a password verification. You don't need to (and shouldn't) store logins and passwords in cookies, and you don't have to store claimed identifiers. Similarly, you don't verify that the login and password matches every time, but remember that the user is authenticated in a session.