依赖 Facebook 用户 ID 作为永久用户标识符
我们正在构建一个 Web 应用程序，现在我们正处于决定如何跟踪用户的阶段。我们的默认选项是维护我们自己的用户注册系统，这很令人头痛（用户名唯一性、注册过程等）。
作为替代方案，我们可以使用人们的 Facebook 身份，这意味着他们将使用 Facebook 的电子邮件和密码登录我们的系统。然后我们的后端将获取用户的 Facebook id（Graph id），并将其存储在数据库中。用户将更改/上传到应用程序的任何数据都将链接到此 ID。
问题是，我们能否信任 id 作为永久标识符，并围绕它构建一个复杂的后端。我们如何确定 Facebook 不会更改某人的 ID？
Azure 访问控制等其他身份管理系统是否依赖此 ID？
We are building a web application and right now we are in the stage of deciding how to keep track of our users. Our default option is to maintain our own user registration system which is a lot of headache (user name uniqueness, registration process, etc...).
As an alternative we can use people's Facebook identity, meaning they will log in to our system using their Facebook's email and password. Then our back-end will fetch the user's Facebook id (Graph id), and store it in the DB. Any data that the user will change/upload to the application will be linked to this id.
The question is, can we trust the id as a permanent identifier, and build a complex back-end around it. How can we be sure that Facebook won't change someone's id ?
Does other identity management systems like Azure Access Control rely on this id?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Facebook 的平台政策不鼓励将用户 ID 用于除内部使用之外的任何用途。因此，如果您计划拥有一个 URL 类似于 /users/ 的个人资料页面，则可能会违反 Facebook 的隐私期望。您最好创建一个带有代理主键的
Users表，并将他们的 facebook id 作为非主列。此外，您可能会遇到这样的情况：用户失去了对旧 Facebook 帐户的访问权限，并希望将您网站上的帐户与新的 Facebook 身份相关联。如果您在多个表中使用他们的 facebook id 作为外键，则不必要地将他们的旧 facebook id 与您的应用程序数据混在一起。
Facebook's platform policy discourages using user ids for anything except internal use. So, if you were planning to have a profile page whose url was something like /users/, it would probably violate facebook's privacy expectations. You're better off making a
Userstable with a surrogate primary key, and including their facebook id as a non-primary column.Additionally, you might run into an instance where a user loses access to their old facebook account and wants to associate their account on your site with a new facebook identity. If you use their facebook id as a foreign key in several tables, you have unnecessarily tangled their old facebook id with your application's data.