答案 0 :(得分：3)
我对Facebook的身份验证/授权方法并不十分熟悉，但我确实认为他们实施oauth（或接近它的东西）进行授权，分布式授权和“单点登录”。
<击> OAuth is described by RFC-5849
编辑：Facebook使用仍在工作草案中的OAuth 2.0。
在OAuth和类似系统中，“access_token”只是图片的一部分。通常还有一个密钥，只有服务提供商（facebook）和客户端应用程序（您的应用程序）才知道。秘密密钥是唯一可以保密的部分 - 而且该部分永远不会通过网络发送（在首次发布之后）。
对于Facebook，我认为在您注册应用程序以使用其API时会为您分配密钥，并且只要用户同意允许您的应用，就会为给定用户返回“access_token”访问他们的信息。
消息以明文形式发送，包括用户的用户名和相关的“access_token”;但是，每条消息还必须包含有效签名才能被服务器接受。签名是加密计算的字符串，使用称为HMAC的技术创建。
计算HMAC签名需要令牌和机密，并且还包括消息的其他关键部分。每个签名对于给定的消息内容是唯一的;每条消息都使用nonce来确保没有两条消息完全相同。
当服务器收到签名消息时，它首先提取access_token（明文），然后确定为其颁发令牌的应用程序。然后，它从自己的本地数据库中检索匹配的 secret （消息中包含 not 的秘密）。最后，服务器使用明文消息，明文access_token和秘密来计算消息的预期HMAC签名。如果计算出的签名与收到的消息上的签名匹配，则该消息必须由知道相同秘密的人（即您的应用程序）发送。
请查看Section 3.1 of RFC-5849了解OAuth特定示例，并进一步详细说明。
顺便提一下，亚马逊使用相同的方法来控制对S3和EC2的访问，以及通过长期授权提供API访问的大多数其他服务提供商。我只想说 - 这种方法是安全的。一开始可能有点反直觉，但一旦你想到它就会有意义。
从Facebook文档添加一些链接和引用：
HMAC-SHA256算法。 注册文件（PHP Example reading signed_request部分）。 signed_request：如果您无法验证
signed_request，因为您无法嵌入 你的申请秘密（例如在 javascript 或桌面应用程序） 那么你MUST只使用一件 来自有效载荷的信息oauth_token。
Security Considerations部分：跨站点请求伪造是一种 其中一个受信任的攻击 （经过身份验证和授权）的用户 在不知不觉中执行了一个动作 网站。为了防止这种攻击，你 应该在州内传递一个标识符 参数，然后验证状态 参数匹配响应。我们 强烈推荐任何应用程序 实施Facebook用户登录 使用它实现CSRF保护 机构。
答案 1 :(得分：0)
Facebook确认确实有一个调用，其中access_token是在open中广播的 - 它恰好是我用来确保用户在保存到我的应用程序数据库之前仍然登录的一个调用。他们的建议是使用截至上个月提供的SSL选项，用于画布和Facebook整体。在大多数情况下，Auth和Auth是安全的。
为了确保第三方应用程序与Facebook应用程序甚至任何使用Facebook单一登录的网站之间的安全接口，身份问题将在与access_token结合使用时提供额外的层。
或要求您的用户使用Facebook和Facebook Canvas应用程序的新SSL功能。如果access_token在打开时广播，则在数据库交互之前需要具有已确认的身份时，它不能用于唯一标识第三方数据库中的任何人。