0

我问了关于我的问题的各种问题（这里和这里），我还在 IRC 上的#oauth & #openid freenode 频道中提问。（这是一个“UP”问题，这是另一个问题）

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

我面临的问题是我如何确定哪个用户正在使用 API（检索他的个人数据，比如你的推文），即使用户正在使用我不知道是谁制作的应用程序（再次，比如 twitter以及周围的所有应用程序）。

我用谷歌搜索了很多，在之前给出的答案的帮助下，我看了一下 OAuth。

据我了解 OAuth 的工作方式，这里如何：

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

到目前为止，一切顺利。但我想不通的是，当用户退出应用程序并再次运行时：应用程序如何记住用户是之前使用它的用户？

（在你们中的一些人给我带来cookie答案之前，我会说这是一个简单的例子，如果用户清除他的 cookie，格式化他的计算机或更改它的计算机，它会是一样的。）

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

这是正确且安全的方法吗？

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!

4

2 回答 2

1

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? Revoking access to apps in Twitter

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.

于 2010-12-31T01:04:12.183 回答
1

if we take a look at how Twitter works, I think the missing point is an other layer to the project: The Official website:

alt text

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:

  • A user goes to a 3rd party application (like a website)
  • This third party redirect the user to the API for Authorization
  • The API redirect the User to the website for Authentication first
  • The official website redirect the User to the OpenId provider (or Facebook connect)
  • The Authentication is made (via multiple requests)
  • The website redirect the user to the API after he's successfully authenticated
  • The user allow/disallow the permissions asked by the 3rd party apps
  • The API returns to the 3rd party apps.
  • The User can now use (or not) the application.

This implementation have 2 problems:

  • Every time an User ins't authenticated (cleared it's cookies, connect himself from an other computer, etc), he will have to go through the Authentication method, by being redirected to the Official website and then being redirected to the 3rd party application (the API would be transparent, since it has already allowed the application to access his data).
  • All those layers would certainly lost the User on the Authentication process with too many redirections.
  • A possible solution would be to store the user's access_token, for example in the case of a mobile app, but with a pure html/css/js oriented app, this isn't possible. A login/password in the 3rd party web application that would match the user to the access_token of the API would be an other solution, like Seesmic (I think), but this is just useless (for us, not Seesmic) : the idea of not having the user's password become useless.

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.

于 2011-01-03T11:36:08.303 回答