针对为第三方应用程序开发人员构建的 API 进行用户身份验证
我正处于为我的网站开发 API 的早期阶段，以便第三方开发人员可以为其构建 iPhone 应用程序。 API 将具有整个站点功能的有限子集。我遇到的问题是下载应用程序的用户的安全性和身份验证。我提出了以下选项：
- 用户输入他们在网站上使用的相同凭据来验证自己的身份。然后，我的 API 将在访问特定于用户的信息时获取凭据。这是我最不喜欢的解决方案，因为第三方应用程序可以记录这些详细信息并在整个站点上恶意使用它们。
- 每个用户在网站上生成一个唯一的密钥，然后可以在应用程序上使用该密钥进行登录。在访问特定于用户的信息时，我的 API 会将 API 密钥作为参数。但主要问题是，一旦用户获得了密钥的访问权限，任何应用程序都可以对用户做他们喜欢做的事情，即使用户没有授予应用程序这样做的权限。
- 为了克服上述问题，第三方开发人员必须在网站上注册他们的应用程序，然后用户需要为他们希望使用的每个应用程序生成一个唯一的密钥。然后这将用于登录。这是我的首选解决方案，因为每个应用程序和用户的每个密钥都是唯一的，我可以知道哪个应用程序调用了 API 以及用户是否批准了它。
- 我的最终选择是实施 oAuth。我们目前正在等待 2.0 版本的最终确定，并且没有时间不断更新我们的代码，因为规范可能会发生变化。
这是我必须构建的第一个 API，我想知道我是否正确理解了这一点？我假设在选项 1 中，应用程序可以记录用户凭据并恶意使用它们，但 Twitter 如何通过其第三方应用程序克服此问题？或者仅仅取决于用户是否信任他们正在使用的应用程序？如果是这种情况，那么在我切换到选项 4 之前，选项 2 和/或 3 是可行的。
非常感谢您的反馈。
I'm in the early stages of developing an API for my site so that third party developers can build an iPhone application for it. The API would have a limited subset of the functionality of the full site. The trouble I have is around security and authentication for the user who downloads the application. I have come up with the following options:
- The user enters the same credentials they use on the site to authenticate themselves. My API would then take the credentials when accessing information specific to the user. This is my least preferred solution as the third party application could log these details and use them maliciously on the full site.
- Each user generates a unique key on the site which they can then use on the app to login. My API would take the API key as an argument when accessing information specific to the user. The main problem though is that any application can do what they like to the user once they gain access to their key even if the user has not given the application permission to do so.
- To overcome the above problem the third party developer would have to register their application with the site and then the user would need to generate a unique key per application they wish to use. This would then be used to login. This is my preferred solution as each key is unique per application and user I can tell which application called the API and whether the user approved it.
- My final option is to implement oAuth. We are currently waiting for the 2.0 version to be finalized and do not have the time to keep updating our code as the spec may change.
This is the first API i have had to build and I was wondering if i have understood this correctly? I'm assuming in option 1 the application could log the user credentials and use them maliciously but how does twitter overcome this issue with their third party applications? Or is it simply up to the user to trust the application they are using? If this is the case then would option 2 and/or 3 be feasible in the meantime until I switch to option 4.
I'd appreciate your feedback.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
OAuth 1 和 OAuth 2 都是可行的选择。但是，您在基本身份验证方面也会取得很大进展（只要它是通过 SSL 进行的）。不要害怕:)
我已经通过 OAuth 1.0 实现了一个 API 提供程序。由于针对许多平台的 OAuth1.0 有很多现成的库，我也不会害怕使用它，对于作为提供者的您和第三方实现者来说，大部分工作已经完成。
无论如何：您始终可以使用应用程序密钥和秘密将基本身份验证与一些非常简单的请求签名结合起来，例如，作为第三方开发人员，您必须致电。
API 实现者必须使用密钥对 random_string、时间戳和 api_key 进行签名。那么你至少会有一种方法来关闭恶意应用程序。
OAuth 1 and OAuth 2 are both viable options. But you will come a long way with basic authentication aswell (as long as it is over SSL). Don't be scared :)
I've implemented an API provider over OAuth 1.0. And since there are so many ready made libraries for OAuth1.0 for many platforms I would not be scared of using that either, much of the work has been done already, both for you as a provider and for third party implementors.
Anyway: you can always couple basic authentication with some very simple signing of the request using an application key and secret, say for example that as a third party developer you have to call.
where the API implementor has to sign perhaps the random_string, timestamp and api_key with the secret. Then you would at least have a way of shutting down malicious apps.