使用第 3 方 OAuth 令牌在自定义用户数据库中创建用户对象？

Question

我们正在创建一个用户可以登录的服务（现在是后端 + iOS 应用程序）。我们已经完成了我们自己的基于令牌的自定义登录系统并进行了注册。我们现在正在尝试实现他们可以选择“通过 Facebook 登录”或“Twitter”等的功能。（即不使用我们的自定义注册用户名和密码）

我们已经成功实现了客户端功能，但是我们从第三方服务（Facebook）收到的只是一个令牌，以及用户的基本信息。

要使用我们的服务，（当然）需要在我们的服务器上注册一个适当的 CustomUser 对象（我们自己的），该对象通常会在我们的自定义注册中创建。通过 3rd 方服务登录时，我们应该如何为该外部认证用户创建 CustomUser-object？

当用户通过我们的应用程序被第三方服务认证时，我们如何以及向我们自己的服务器发送什么来注册（或认证）？ 我们收到一个 auth-token（最终会过期），并且应用程序（客户端）可以访问第 3 方的用户基本信息。我们正在考虑将基本信息（例如用户的 user_id 和电子邮件以及令牌）发送到我们自己的服务器，并为它创建一个新的用户对象（如果它以前不存在）。但是，我们意识到这根本不是很安全。当用户下次登录我们的服务时，使用相同的 3rd 方身份验证，我们只有用户 user_id 和 email 来匹配。该令牌可能是一个新令牌。这意味着任何拦截到我们服务器的任何第 3 方登录调用的人都会看到，基于第 3 方身份验证登录到现有 customUser 所需的唯一信息是 user_id 和电子邮件。在大多数此类 3rd 方服务（例如 Facebook）上非常公开。

我们一直在尝试使用这些 3rd 方服务阅读 OAuth 和授权/身份验证，但我们看到的每一个文档都痛苦地专注于 3rd 方身份验证，并且没有触及 我们自己的第 3 方身份验证..

我们做错了吗？

Answer 1

实际上，您关于电子邮件和 user_id 的断言并不完全正确，至少对于 Facebook 而言。

... 在大多数此类 3rd 方服务上非常公开，例如 脸书。

当有人通过 Facebook Oauth 服务登录时，您将获得一个“app_scoped_user_id”，这是 Facebook 为用户和您的应用创建的唯一 ID。每个用户对于他使用的每个应用程序都有不同的“应用程序范围用户 ID”，除了您（应用程序）之外没有人会知道“应用程序范围用户 ID”。

App scope user id docs

所以我想说使用“应用范围用户 ID”作为用户的标识符是安全的，也是最好的方法。

不确定它如何与 Twitter 等其他服务一起使用，但我很确定您可以做类似的事情。即使 user_id 是公开的，它也应该始终是唯一的，您可以使用它来识别您自己的用户。

希望对你有帮助。