Restful API，应用程序如何（重新）将用户与现有用户匹配？
我问了有关我的问题的各种问题（这里和这里），我也在#oauth & 中问过。 IRC 上的 #openid freenode 频道。 （这是一个“UP”问题，这是另一个问题）
我将总结我的项目配置：任何人都可以创建一个可以使用我的 API 的应用程序。首先，我将开发我的 API 和基于 Web 的应用程序，但有关 API 的文档将是公开的。它有点像 Twitter API。
我面临的问题是如何确定哪个用户正在使用 API（检索他的个人数据，例如您的推文），即使该用户正在使用一个我不知道是谁制作的应用程序（同样，例如 twitter）以及周围的所有应用程序）。
我用谷歌搜索了很多，并在前面给出的答案的帮助下，我查看了 OAuth。
据我了解 OAuth 的工作方式，如下：
- 用户访问使用我的 API（网络、移动等）的应用程序
- 应用程序将用户重定向到 API 进行身份验证（我将使用 OpenId）和授权（OAuth）。这有点奇怪，因为 API 将有一个用于登录和授权的 Web 界面（我想这就是它的工作原理，因为 Twitter 这样做）
- API 使用一些令牌将连接的用户重定向到应用程序。在这些令牌中，有一个代表应用程序必须存储的用户的令牌，以便向 API 指示当前哪个用户正在使用它（我正确吗？）
到目前为止，一切顺利。但我无法弄清楚的是，当用户退出应用程序并再次进入时：应用程序如何记住用户是之前使用过它的用户？
（在你们中的一些人给我提供 cookie 答案之前，我会说这是一个简单的例子，如果用户清除他的 cookie、格式化他的计算机或更改其计算机，情况是一样的.)
我能找到的唯一解决方案是，当未经身份验证的用户（例如没有记住 cookie）访问应用程序时，应用程序将他再次重定向到 API 以验证自己的身份，但这一次，用户赢了不必重新允许该应用程序（授权），因为它已经这样做了。然后，API 会将用户返回到应用程序以允许他使用该应用程序。
这是正确的吗？ 安全的方式来做到这一点？
#OAuth IRC 频道告诉我有关新协议 WebID 的信息，但这目前处于预草案模式，我不想使用将来会不断更改的内容：/
非常感谢您的帮助！
I asked various questions about my problem (here and here) and I also asked in the #oauth & #openid freenode's channel on IRC. (this is note an "UP" question, it's an other problem)
I'll sum up my project configuration : Anyone will have the possibility to create an app that can use my API. To start, I'll work on my API and a Web based app, but the documentation about the API will be public. It's a bit like Twitter API.
The problem I face is how can I be sure which user is using the API (to retrieve his personal data, like your tweets), even if the User is using an app that I don't know who make it (again, like twitter and all the apps around).
I googled a lot and with the help of the previous answers given, I took a look at OAuth.
As far as I understood the way OAuth works, here how :
- A user visit an app that use my API (web, mobile, whatever)
- The apps redirect the user to the API for the authentication (I'll use OpenId) and the authorization (OAuth). This is a bit odd since the API will have a web interface for the login and the authorization (I suppose this is how it works since Twitter do that)
- The API redirect the connected user to the app, with some tokens. In these tokens, there is a token representing the user that the app must store in order to indicate to the API which user is using it currently (Am I correct?)
So far, everything goes well. But what I can't figure it out, is when the user quit the app and goes again : how the app can remember the user is the one that used it before ?
(Before some of you bring me the cookie answer, I'll remark this is a simple example, it would be the same if the user clear his cookies, format his computer or change its computer.)
The only solution I can find, is when an unauthenticated user (without a remembering cookie for example) goes to the app, the app redirect him again to the API to authenticate himself, but this time, the user won't have to re-allow the app (authorization) since it already did it. The API will then return the user to the app to allow him to play with this.
Is this the proper & secure way to do it ?
The #OAuth IRC channel told me about the new protocol, WebID, but this is currently in pre-draft mode and I don't want to use something that will change continuously in the future :/
Thank you very much for your help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
简短回答：OAuth 会生成经过身份验证的访问令牌。该访问令牌与一个用户绑定。只要访问令牌有效。第三个应用程序可以执行 API 允许访问令牌执行的任何操作。
长答案：
OAuth 的问题是它不会“登录”用户。 OAuth 为第三方应用程序提供了所谓的访问令牌，该令牌可用于代表用户访问数据，无论他/她是否登录。
许多服务限制其访问令牌。例如，Twitter 颁发两种类型的访问令牌：只读和读/写。但没有登录使用API的概念。当访问令牌有效时，第三方应用程序可以访问用户的数据，并在无需用户显式交互的情况下进行更改。
大多数 API 提供商都具有撤销访问令牌的功能。这就是当您在 Twitter 中查看 连接页面 时发生的情况。看到撤销访问链接了吗？
我个人喜欢 OAuth 方法。作为 API 提供商，您可以控制允许访问令牌执行哪些操作，并且用户可以通过使用其资源来终止不良应用程序。就身份验证而言，OAuth 是安全的。第三方应用程序不会获取用户的密码。但一旦经过身份验证，他们就可以执行 API 允许的任何操作。
Short answer: OAuth results in an authenticated access token. That access token is tied to ONE user. And as long as the access token is valid. The third application can do whatever the API allows the access token to do.
Long answer:
The thing with OAuth is that it does not "Log in" a user. OAuth gives third party applications what is called access tokens which can be used to access data on behalf of a user whether he/she is logged in or not.
Many services restrict their access tokens. Twitter for example issues two types of access tokens, read-only, and read/write. But there is no concept of logging in to use APIs. While an access token is valid, a third party application can access the user's data, and change things without a user's explicit interaction.
Most API providers have functionality to revoke access tokens. That is what happens when you in twitter look at your Connections page . See the revoke access links?
Personally I love the OAuth approach. As an API provider, you can control what access tokens are allowed to do, and the user can kill bad applications from using his/her resources. OAuth is secure as far as authentication goes. Third party applications do not get hold of user's passwords. But once authenticated they can do whatever your API allows.
如果我们看一下 Twitter 的工作原理，我认为缺少的一点是该项目的另一层： 官方网站：
是，当您想要允许任何第 3 方应用程序使用 Twitter 时，此应用程序会将您重定向到 Twitter API 的 OAuth 页面（如果您已连接），但如果没有连接，它会将您重定向到登录页面，位于 http://api.twitter.com/login
（我不知道将 api 保留在 api.twitter.com 中用于登录用户是否正确，而不仅仅是 twitter.com 是否正确，但这只是语义）
因此，工作流程将是：
此实现有两个问题：
这是一个可能的解释，但我需要更多关于如何实现这一点的详细信息以及您对该解决方案的想法。会起作用吗？
（我将其添加为答案，因为它是一个（不完整且不太确定，我同意）答案。
if we take a look at how Twitter works, I think the missing point is an other layer to the project: The Official website:
The thing is, when you want to allow any 3rd party application to use Twitter, this application redirect you to the OAuth page of the Twitter API, IF you are connected, but if you aren't, it redirect you to the login page, which is located at http://api.twitter.com/login
(I don't know if keeping the api in api.twitter.com for loging an user, instead of just twitter.com is correct, but this is just semantics)
So, the workflow would be:
This implementation have 2 problems:
This is a possible explanation but I would require more details on how this is possible and your thought about that solution. Would it work?
(I added this as an answer since it's an (incomplete and not so sure, I agree) one.