Restful API，应用程序如何（重新）匹配用户与现有用户？

Question

我询问了有关我的问题的各种问题（here和here），我也在#oauth＆amp; #open freenode在IRC上的频道。 （这是一个“UP”问题，这是另一个问题）

我将总结我的项目配置：任何人都可以创建一个可以使用我的API的应用程序。首先，我将使用我的API和基于Web的应用程序，但有关API的文档将是公开的。这有点像Twitter API。

我面临的问题是我如何确定哪个用户正在使用API​​（检索他的个人数据，如推文），即使用户正在使用我不知道是谁创建的应用程序（再次，就像推特和周围的所有应用程序一样。）

我搜索了很多内容，在前面给出的答案的帮助下，我看了看OAuth。

据我所知，OAuth的工作方式如下：

• 用户访问使用我的API（网络，移动设备，等等）的应用
• 应用程序将用户重定向到用于身份验证的API（我将使用OpenId）和授权（OAuth）。这有点奇怪，因为API将有一个用于登录和授权的Web界面（我想这是自Twitter do that以来它是如何工作的）
• API将连接的用户重定向到应用程序，并带有一些令牌。在这些令牌中，有一个表示应用必须存储的用户的令牌，以便向API指示当前正在使用哪个用户（我是否正确？）

到目前为止，一切顺利。但我无法弄明白的是，当用户退出应用程序并再次运行时：应用程序如何记住用户之前是否使用过它？

（在你们有些人给我带来 cookie 答案之前，我会说这是一个简单的例子，如果用户清除他的cookie，格式化他的电脑或者改变它的电脑。）

我能找到的唯一解决方案是，当未经身份验证的用户（例如没有记忆cookie）进入应用程序时，应用程序会再次将他重定向到API以验证自己，但这次，用户将不会重新允许应用程序（授权），因为它已经做到了。然后，API会将用户返回到应用程序以允许他玩这个。

这是正确的吗？ 安全这样做的方法吗？

#OAuth IRC频道告诉我有关新协议WebID的信息，但目前处于预选模式，我不想使用将来会不断变化的内容：/

非常感谢你的帮助！

Answer 1

简短回答：OAuth会生成经过身份验证的访问令牌。该访问令牌与一个用户绑定。只要访问令牌有效。第三个应用程序可以执行API允许访问令牌执行的任何操作。

答案很长： OAuth的一点是它不会“登录”用户。 OAuth为第三方应用程序提供了所谓的访问令牌，无论用户是否已登录，都可以代表用户访问数据。

许多服务限制其访问权限。例如，Twitter发布两种类型的访问令牌，只读和读/写。但是没有登录使用API​​的概念。虽然访问令牌有效，但第三方应用程序可以访问用户的数据，并在没有用户明确交互的情况下进行更改。

大多数API提供商都具有撤销访问令牌的功能。当你在twitter中查看你的Connections page时会发生这种情况。查看撤销访问链接？

我个人喜欢OAuth方法。作为API提供程序，您可以控制允许访问令牌执行的操作，并且用户可以使用他/她的资源来杀死不良应用程序。就身份验证而言，OAuth是安全的。第三方应用程序不会获取用户的密码。但经过身份验证后，他们可以执行API允许的任何操作。

Answer 2

如果我们看看Twitter如何运作，我认为缺少的一点是项目的另一层：官方网站：

问题是，当您想允许任何第三方应用程序使用Twitter时，此应用程序会将您重定向到Twitter API的OAuth页面，如果您已连接，但如果您不是，则会将您重定向到登录页面，位于http://api.twitter.com/login （我不知道是否在api.twitter.com中保留api用于登录用户，而不仅仅是twitter.com是正确的，但这只是语义）

因此，工作流程将是：

• 用户转到第三方应用程序（如网站）
• 此第三方将用户重定向到API以进行授权
• API将用户重定向到首先进行身份验证的网站
• 官方网站将用户重定向到OpenId提供商（或Facebook连接）
• 进行身份验证（通过多个请求）
• 网站在成功通过身份验证后将用户重定向到API
• 用户允许/禁止第三方应用提出的权限
• API返回第三方应用。
• 用户现在可以使用（或不使用）应用程序。

此实现有两个问题：

• 每次用户都没有通过身份验证（清除它的cookie，从另一台计算机上连接自己等），他将不得不通过身份验证方法，重定向到官方网站，然后重定向到第三派对应用程序（API将是透明的，因为它已经允许应用程序访问他的数据）。
• 所有这些图层肯定会在身份验证过程中丢失重定向过多的用户。
• 可能的解决方案是存储用户的access_token，例如在移动应用程序的情况下，但使用纯html / css / js导向的应用程序，这是不可能的。第三方Web应用程序中与用户匹配API的access_token的登录名/密码将是另一种解决方案，如Seesmic（我认为），但这对我们来说是无用的（对我们而言，不是Seesmic）：没有用户密码就没用了。

这是一个可能的解释，但我需要更多详细信息，了解这是如何可行的以及您对该解决方案的想法。它会起作用吗？

（我补充说这是一个答案，因为它是一个（不完整，不太确定，我同意）一个。