如何在服务器端使用Facebook用户访问令牌？
前言 我正在开发几个Web服务和少数客户端（Web应用程序，移动设备等），它们将通过HTTP与上述服务进行交互。我当前的工作项目是为产品设计身份验证和授权解决方案。我已决定利用外部身份提供者（例如Facebook，Google，Microsoft，Twitter等）进行身份验证。 我正在尝试解决以下问题：“当有请求发送到服务器时，我怎么知道用户是谁，如何确定？”。下面还有更多问题... 要求 依靠外部身份来表明我正在与谁打交道（'userId'本质上就是我关心的全部）。 系统应使用基于令牌的身份验证（例如，相对于cookie或基本身份验证）。 我相信这是跨多个客户端和服务器扩展同时提供松散耦合的正确选择。 工作流程 根据我对基于令牌的身份验证的阅读和理解，以下是我对工作流程的想象。现在让我们通过网络浏览器关注Facebook。我的假设是，其他外部身份提供商应具有类似的功能，尽管我尚未确认。 请注意，在撰写本文时，我基于以下Facebook登录版本2.2 客户端：使用JavaScript SDK启动登录Facebook Facebook：用户验证并批准应用权限（例如，访问用户的公开资料） Facebook：将响应发送到客户端，其中包含用户的访问令牌，ID和已签名的请求 客户端：将用户访问令牌存储在浏览器会话中（由SDK方便地处理） 客户端：通过在授权标头+用户ID（可能在自定义标头中）中发送用户的访问令牌，向我的Web服务请求安全资源 服务器：从请求标头读取用户访问令牌，并通过向Facebook提供的debug_token图API发送请求来启动验证 Facebook：使用用户访问令牌信息来响应服务器（包含appId和userId） 服务器：通过将appId与期望值（自身已知）进行比较，并将userId与客户端请求中发送的内容进行比较，从而完成令牌的验证 服务器：使用请求的资源响应客户端（假设授权路径愉快） 我在想象对服务器的后续请求将重复执行步骤5-9（而用户的访问令牌有效–未过期，从FB端撤消，更改应用权限等） 这是一个有助于执行步骤的图表。请了解该系统不是单页应用程序（SPA）。提到的Web服务是从本质上将JSON数据返回给客户端的API端点。它们不提供HTML / JS / CSS（Web客户端服务器除外）。 问题 首先，基于我的序言和要求，上述方法是否存在明显的缺口/凹坑？ 是否需要/建议向Facebook执行出站请求以验证每个客户请求的访问令牌（上述步骤6-8）？ 我至少知道，我必须验证来自客户端请求的访问令牌。但是，对于第一次验证之后的后续验证，推荐的方法对我来说还是未知的。如果有典型的模式，我很想听听它们。我了解，根据我的要求，它们可能取决于应用程序；但是，我只是不知道要寻找什么。一旦有了基本思路，我将进行尽职调查。 例如，可能的想法： 第一次验证完成后，将访问令牌+用户ID对散列，并将其存储在分布式缓存（可由所有Web服务器访问）中，并且到期时间等于访问令牌。根据来自客户端的后续请求，对访问令牌+ userId对进行哈希处理，并检查其在缓存中的存在。如果存在，则请求被授权。否则，请联系Facebook图形API确认访问令牌。我假设如果使用HTTPS（将会），则该策略可能可行。但是，性能如何比较？ 在这个StackOverflow问题中可接受的答案建议在对Facebook用户令牌的第一次验证完成后创建一个自定义访问令牌。然后，将自定义令牌发送到客户端以进行后续请求。我想知道这是否比上述解决方案更复杂。这将需要实现我自己的身份提供者（我想避免的事情，因为我想首先使用外部身份提供者……）。这个建议有什么好处吗？ 上面的步骤3中的响应上是否存在signedRequest字段（在此处提到），是否等同于“游戏画布登录”流程中此处的signed请求参数？ 似乎暗示它们是等效的，因为在文档中前者链接到后者。但是，令我感到惊讶的是，网络文档的“手动构建登录流程”页面中没有提到游戏页面上提到的验证策略。 如果对＃3的回答为“是”，是否可以使用相同的身份确认策略对签名进行解码并与预期在服务器端使用的身份进行比较？ 我想知道是否可以利用此方法来代替对debug_token图API的出站调用（上述步骤＃6），以按照此处的建议确认访问令牌： 当然，为了在服务器端进行比较，需要将签名的请求部分与请求一起发送到服务器（上述步骤＃5）。除了在不牺牲安全性的情况下的可行性之外，我想知道与拨打外拨电话相比，性能如何。 当我在使用它时，在什么情况下/出于什么目的，例如，您会将用户的访问令牌持久化到数据库吗？我看不到需要这样做的情况，但是，我可能会忽略某些事情。我很好奇某些常见情况可能会引发一些想法。 谢谢！