我们有一个网站，登录和验证自己的网站的唯一方法是使用Facebook（这不是我的选择） . 第一次使用Facebook登录时，会自动为您创建一个帐户 .
我们现在想为我们的网站创建一个iPhone应用程序，也为其他人创建一个公共API来使用我们的服务 .
这个问题是关于如何通过app / API对我们的网站进行身份验证，并分为两部分：
- 从API到只使用Facebook OAuth作为身份验证方法的网站处理REST身份验证的正确方法是什么？
我已经阅读并研究了很多关于REST API的标准身份验证方法 . 我们不能使用像Basic Auth over HTTPS这样的方法，因为用户没有这样的凭证 . 像this似乎仅用于使用API验证应用程序 .
目前，我认为最好的方法是在API上点击/授权 endpoints ，重定向到Facebook OAuth，然后重定向回网站，并提供API的用户可以用来验证后续的“令牌”要求 .
- 对于我们创建的官方应用程序，我们不一定需要以相同的方式使用公共API . 那么与我们的网站交流和验证用户的最佳方式是什么？
我理解（我认为）如何使用API（公共）密钥和秘密（私有）密钥对使用我们的API的第三方应用程序进行身份验证 . 但是，在对使用该应用程序的用户进行身份验证时，我对如何进行此操作感到困惑，因为我们必须对用户进行身份验证的唯一方法是Facebook .
我觉得我错过了一些非常明显的东西，或者没有完全理解公共REST API应该如何工作，所以任何建议和帮助将不胜感激 .
3 回答
更新：见下文
我还不完全清楚，但这是我想要的路线 . 我正在创建一个REST API，我的用户只能使用Facebook连接进行身份验证 .
在客户端：
使用Facebook API登录并获取OAUTH2代码 .
将此代码替换为访问令牌 .
在每次调用我的自定义API时，我都会包含Facebook用户ID和访问令牌 .
在API上（对于需要用户身份验证的每种方法）：
使用上面的访问令牌向/我Facebook图表发出请求 .
确认返回的Facebook用户ID与从上面传递给我的API的用户ID相匹配 .
如果访问令牌已过期，则需要进行额外的通信 .
我还没有测试过这个 . 听起来怎么样？
---更新：2014年7月27日回答问题---
登录时我只使用上述交换一次 . 一旦我确定登录了哪个用户，我就会创建自己的访问令牌，并且从那一点开始使用该令牌 . 所以新流程看起来像这样......
在客户端：
使用Facebook API登录并获取OAUTH2代码 .
将此代码替换为访问令牌 .
从我的API请求访问令牌，包括Facebook令牌作为参数
在API上
接收访问令牌请求 .
使用facebook访问令牌向/我Facebook图表发出请求
验证Facebook用户是否存在并与我的数据库中的用户匹配
创建我自己的访问令牌，将其保存并将其返回到客户端，以便从此时开始使用
这是我使用JWT（JSON Web令牌）的实现，基本上类似于Chris的更新答案 . 我使用过Facebook JS SDK和JWT .
这是我的实施 .
Client: 使用Facebook JS SDK登录并获取访问令牌 .
Client: 通过调用
/verify-access-tokenendpoints 从我的API请求JWT .MyAPI: 接收访问令牌，通过调用Facebook API的
/meendpoints 进行验证 .MyAPI: 如果访问令牌有效，则从数据库中查找用户，如果存在，则登录用户 . 创建一个JWT，其中包含必填字段作为有效负载，设置到期日期，使用密钥签名并发送回客户端 .
Client: 将JWT存储在本地存储中 .
Client: 发送令牌（步骤5中的JWT）以及下一次API调用的请求 .
MyAPI: 使用密钥验证令牌，如果令牌有效，则将令牌换成新令牌，将其与API响应一起发送回客户端 . （之后没有外部API调用以验证令牌）[如果令牌无效/过期请求客户端再次进行身份验证并从1开始重复]
Client 用新的令牌替换存储的令牌，并将其用于下一次API调用 . 一旦满足令牌到期，令牌就会终止撤销对API的访问 .
每个令牌都使用一次 .
阅读有关安全性和JWT的更多答案
How secure is JWT
If you can decode JWT how are they secure?
JSON Web Tokens (JWT) as user identification and authentication tokens
我想回答同样的问题，并且最近经历了很多阅读......
我不会回答，但事情正在发生对我来说更清楚一点 . 你有没有读过the article you mentioned中的评论？我发现它们非常有趣且有用 .
因此，根据自第一篇文章撰写以来事物的演变，以下是我认为我会做的事情：
HTTPS无处不在 - 这让你忘记了HMAC，签名，现时，......
使用OAuth2：
当身份验证请求来自我自己的应用程序/网站时，请使用前面提到的reply to the article中描述的'trick'（或其变体） .
就我而言，我有两种类型的用户：具有经典登录/密码凭据的用户和已注册Facebook Connect的用户 .
所以我'd provide a regular login form with a 1059538 button. If the user logs in with his 1059539 credentials, I'只需使用
grant_type=password将这些发送到我的OAuth2 endpoints .如果他选择通过Facebook登录，我认为这将是一个两步骤的过程：
首先，使用Facebook iOS SDK打开FBSession
当's done and the app is given back control, there should be a way to get a Facebook ID for that user. I'd将此ID单独发送到我的OAuth2 endpoints 时，extension grant被我的服务器理解为"using an FB User ID" .
请注意，我仍然在研究所有这些东西，所以这可能不是一个完美的答案......也许甚至不是一个正确的答案！但我认为这将是一个很好的起点 . 使用“扩展授权”进行Facebook身份验证的想法可能需要注册才能正确执行操作？我不太确定 .
无论如何，我希望我能够帮助你一点，至少它可以开始讨论找到这个问题的最佳解决方案:)
Update
Facebook登录不是评论中指出的解决方案：任何人都可以发送任意用户ID并以此用户身份登录API .
怎么样这样做：
使用"Facebook login"按钮显示登录表单
如果选择此登录方法，请像Facebook SDK一样：从您的身份验证服务器打开一个网页，该网页将启动Facebook登录 .
用户登录后，Facebook将使用您的重定向网址进行确认;使该URL指向您的身份验证服务器的另一个 endpoints （可能有一个额外的参数，表明该呼叫来自一个应用程序？）
当验证 endpoints 被命中时，身份验证可以安全地识别用户，保留其FB用户ID / FB会话并使用自定义URL方案向您的应用返回访问令牌，就像Facebook SDK会做的那样
看起来更好？