我应该如何构建RESTful Web服务以使用第三方（即Google，Facebook，Twitter）进行身份验证？

对于我的工作，我们有一个不错的RESTful Web服务，我们已经建立了该服务，用于驱动我们拥有的几个网站。基本上，Web服务使您可以创建和使用支持凭单，并且网站负责前端。任何网络服务请求都使用auth标头，我们使用该标头来验证用户及其每次呼叫的密码。

今年，我们正在寻求扩展登录选项，以便网站上的用户可以通过Google，Twitter和Facebook（可能还有其他）登录。但是，我在弄清楚如何设计该结构方面很麻烦，因此Web服务可以使用第三方身份验证提供程序来确保用户就是他们所说的。是否有最佳实践来做到这一点？

当前，我们正在考虑让网站处理用户本身的身份验证，然后使用一个新的setSessionId调用来将其当前会话注册到Webservice后端。对Web服务的每个其他请求都将传递该sessionId并将对其进行验证。这些看起来还可以，但是我的内心深处感到我没有考虑透彻，所有浏览和阅读oauth和openid规范的论坛都让我更加困惑。有什么技巧可以解决这个问题吗？

听起来有两个目标：

1. 最终用户易于通过其现有社交帐户进行身份验证
2. 易于使用Web服务的开发人员

由于客户端库的普及和可用性，授权人们使用您网站上的资源使OAuth2成为首选的机制。

1.便于最终用户使用其现有的社交帐户进行身份验证

最终用户访问使用您的API的站点并选择登录。它们被发送到您的OAuth登录页面。您的登录页面会显示一个正常的用户名和密码提示，提示您在网站上管理的帐户，以及一组社交身份验证按钮，用户可以单击它们以通过Facebook等网站登录。当用户选择Facebook时，您会将他们重定向到Facebook以批准选择（启动Facebook身份验证流程）。最终用户在Facebook上完成登录后，他们将被重定向回您的站点。

当用户从Facebook重定向回您的站点时，您会将用户的信息保存到数据库中的用户记录中，然后为该用户生成新的会话。您立即使用oauth access_token将最终用户重定向到其原始下游站点，从而完成原始oauth流。

2.方便开发人员使用您的Web服务

如果您是授权的提供者，则应为开发人员创建一个简单的界面，以使其每次添加新的上游auth提供者时都不会更改，而该提供者并不能完美地实现oauth。这就是为什么我认为您应该实施OAuth2提供程序网站，并且该网站应该是社交身份验证网站的使用者的原因。

对于使用您的Rest API的开发人员而言，除非您选择通过会话捕获帖子向他们提供提示，否则他们将不会意识到Facebook的交互作用。

TL; DR

通过实现OAuth2并隐藏社交身份验证的复杂性，使您的API使用者像您一样。您可以在下游站点的oauth流程中，通过facebook触发其他oauth流程。

图片，因为图片==字* 1000：

我们可以称之为oauth2-piggy-back吗？

循序渐进的流程

1. 最终用户访问使用您的API的网站
2. 最终用户被发送到您的网站以进行授权或注册（oauth2）
3. 最终用户选择社交身份验证，单击facebook登录按钮
4. 您的网站设置cookie或state在facebook oauth中设置，以了解用户来自何处
5. 最终用户重定向到Facebook，并接受Facebook网站上的连接
6. 最终用户重定向到您的网站以完成Facebook身份验证过程
7. 您在数据库中查找或创建用户
8. 您在服务器上创建一个新会话
9. 您使用会话令牌将用户重定向回其原始站点

如何使其可扩展

首先，您应该注意到所有这些api使用相同的登录机制。它们都使用OAuth进行身份验证。您需要从一般的OAuth库开始利用这一点。不要使用自己的库进行身份验证，这些库对其他提供程序将不可用。如果您不熟悉OAuth2，则添加更多提供程序非常容易。

不幸的是，您需要两个，因为twitter仍然没有跳过OAuth2的潮流。

OAuth需要您为身份验证方创建一个接口。令牌将在服务器之间交换。创建一个可以处理所有通信的入口点。

令牌应与您的帐户存储在单独的表中，这是因为令牌可以是多个令牌和多个链接的配置文件。有些服务为您提供两个令牌，其中之一是刷新令牌。

现在，您设计一个接口，该接口封装了您所需的其他功能。我将为此设置一个单独的REST服务。这样，您可以轻松地将身份验证扩展到其他地方。
一些服务使用JSON进行通信，其他服务则使用XML等。对于高级用户，您需要统一它们。这是一个非常痛苦的过程，但是有可能在这里得出一些共同点。

这里的另一个问题是，并非所有服务都提供相同的功能。这可能意味着您的服务无法提供您指定的完整API。您需要在这里制定一个策略，该策略可以使应用程序正常降级。

这一切都将确保您可以轻松添加新的第三方提供商。

代币问题

令牌的时间有限，因此您需要执行两个cron作业，这些作业可以检查令牌是否仍然可用，否则必须将其删除。您也可以通过此机制刷新令牌。

用户有时会收回令牌。为此做好准备。

数据存储

如果您有这种设计，则需要考虑所需的数据。这部分来自您刚创建的界面。为此设计一些表，并查看数据是否实际可检索。某些服务不允许您获取大量数据。您还应该考虑到，所需的数据越多，隐私消息就越重。因此，请谨慎处理您的需求，否则用户将不会使用它。

为了进行额外的验证，您可以将配置文件存储在单独的但链接到用户的表中。这将为您提供有关某人的更多信息。

还要检查您当地的法律，对于某些数据，您需要采取额外的预防措施。

最后一件事 不要在不使用自己的服务创建帐户的情况下犯错。如果用户被禁止使用Facebook，他将实际上无法登录您的服务。这是您不想创建的情况。这经常被忽略。

我肯定会采用听起来像您已经想通的解决方案：在面向客户的网站上实施第三方身份验证，然后将这些第三方身份验证令牌与您的网站用户帐户相关联，然后最终触发您的setSessionID调用登录。

根据您的网站架构，您可能会发现使用EveryAuth或Passport之类的库会很有帮助。

我的两分钱：我以前从未做过这样的事情，也不知道FB，Twitter或Google登录机制的工作原理，但是一旦我读到你的问题，我就会想到一些问题：

• 多次登录：如果我有一天使用Facebook帐户登录，而第二天又使用Google帐户登录，会发生什么情况？还是同时？您是否将这两个帐户视为唯一的独立帐户，还是应该采用某种方法来关联这两个帐户并允许我以任何一种方式访问​​我的门票？
• 依靠外部标识符：当Facebook或Twitter决定更改其帐户标识符的外观时，会发生什么？为了说明这一点，如果BazLogin使用代码{4382-af56}表示一个唯一帐户，但由于8位数字不足而决定从现在开始帐户将具有12位数字，您如何从{0000-4382告诉{1234-4382-af56} -af56}？

我们可以通过选择将外部帐户与内部帐户（而不仅仅是会话ID）相关联来处理这两个问题。然后，外部登录可能只是一个网关创建内部帐户。如果我使用一种以上的登录方法进行身份验证，您可以告诉我我已经登录。如果外部身份验证提供程序更改了我们所依赖的内容，我们可以要求用户提供其内部帐户的名称和密码，并创建一个未来登录的新关联。

我不确定我是否已解决您所想到的问题，但您并未真正提及任何具体问题。无论哪种方式，我希望我的回答都对您有所帮助。