使用 OAuth 保护我的 REST API，同时仍然允许通过第三方 OAuth 提供商进行身份验证（使用 DotNetOpenAuth）
我有一个具有简单 REST API 的产品，以便该产品的用户可以直接集成该产品的功能，而无需使用我的 Web 用户界面。
最近，各个第三方都对我感兴趣，希望将他们的桌面客户端与 API 集成，以允许我的产品的用户使用该第三方应用程序访问他们的数据。
我发现想要使用 Twitter 的应用程序使用 Twitter 托管的登录页面进行身份验证，该登录页面授予特定应用程序访问该用户数据的权限。单击“允许”或“拒绝”按钮，身份验证过程即完成。据我所知，Facebook 使用的是相同的机制。
经过进一步研究，这似乎是 OAuth 在起作用，并且鉴于我的 API 是基于 .Net 的，我认为我应该使用 DotNetOpenAuth 并提供类似的机制。不幸的是，这些示例的记录很少（如果有的话），我在网上找到的唯一教程似乎集中于帮助您为用户提供登录机制，以便他们可以使用第三方提供商登录您的网站。
我真正想做的是让我的 REST API 处理我的 Web 应用程序的所有核心身份验证和业务逻辑，并且在幕后，我的 Web 应用程序本质上是另一个仅使用通过 OAuth 的 API。用户可以直接使用用户名和密码，或者通过第三方提供商（例如 MyOpenID 或 Facebook）在网站上进行身份验证，然后网站将以某种方式使用返回的令牌根据 REST API 进行身份验证。
基本上看起来我需要我的 API 以某种方式托管 OAuth 服务，但也让用户使用第三方 OAuth服务。我情不自禁地认为我对 OAuth 没有足够的了解，无法确定我是否使事情变得过于复杂，或者我正在尝试做的事情是好是坏。
有人可以至少让我大致了解一下我需要采取的步骤，或者我应该注意什么才能实现这一目标吗？或者给我一些教程？或者抨击我的提案并告诉我我的做法（在架构上）完全错误？
I have a product with a straightforward REST API so that users of the product can directly integrate with the product's features without using my web user interface.
Recently I have been getting interest from various third parties about integrating their desktop clients with the API to allow users of my product to access their data using that third party application.
I've seen that applications that want to use Twitter authenticate using a login page hosted by Twitter that grants a specific application permission to access that user's data. You click the "Allow" or "Deny" button and the authentication process is complete. Facebook uses the same mechanism as best I can tell.
Upon further research, this seems to be OAuth in action, and seeing as my API is .Net-based, I am thinking I should use DotNetOpenAuth and provide a similar mechanism. Unfortunately the samples are sparsely documented (if at all) and the only tutorials I can find online seem to be focussed on helping you provide a login mechanism for your users so that they can log into your website using a third party provider.
What I would really like to do is have my REST API handle all of the core authentication and business logic for my web application and have, under the hood, my web application essentially be another application that just uses the API via OAuth. Users would authenticate on the website either directly using their username and password, or via a third party provider such as MyOpenID or Facebook and then the website would somehow use the returned token to authenticate against the REST API.
It basically looks like I need my API to somehow host an OAuth service, but also have users use a third party OAuth service. I can't help but think I don't quite have enough of a grasp on OAuth to decide if I'm overcomplicating things or if what I'm trying to do is a good or bad way to do things.
Can someone give me at least a broad overview of the steps I need to undertake, or what I should look at to make this happen? Or point me at some tutorials? Or blast my proposal and tell me I'm going about this (architecturally) all wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，我想强调身份验证和授权之间的区别：
用户通过提供一些凭据（例如用户名+密码）来对您的网站进行身份验证。 OpenID 允许通过让用户向另一个服务进行身份验证来取代这一点，然后该服务代表用户向您的网站断言用户的身份。您的网站信任第三方服务（OpenID 提供商），因此认为用户已登录。
服务或应用程序不会对您的网站进行身份验证 - 至少不会通常。用户授权服务或应用程序访问用户的数据。这通常是通过应用程序请求服务提供商的授权来完成的，然后将用户发送到服务提供商，用户首先进行身份验证（以便服务提供商知道它在与谁交谈），然后用户对站点说“是的， [应用程序]可以[以某种受限的方式]访问我的数据”。从那时起，应用程序使用授权令牌来访问服务提供商站点上的用户数据。请注意，应用程序不会像用户一样对自身进行身份验证，但它使用另一个代码来确保服务它有权访问特定用户的数据。
因此，明确了这种区别后，您可以在网站上完全独立地做出有关身份验证和授权的决策。例如，如果您希望用户能够使用以下所有内容登录：用户名+密码、OpenID 和 Facebook，您可以这样做。一个完全正交的决定是如何授权应用程序（有许多协议可以用于此目的，OAuth 当然非常流行）。
OpenID 专注于用户身份验证。 OAuth 专注于应用程序授权。然而，Facebook 和 Twitter 等少数服务选择使用 OAuth 进行身份验证和授权，而不是使用 OpenID 进行身份验证和 OAuth 进行授权。
现在，对于您自己的项目，我强烈建议您查看 ASP.NET MVC 2 OpenID 网站 (C#) 项目模板可从 VS Gallery 获取。它开箱即用，支持 OpenID 身份验证和 OAuth 服务提供商。这意味着您的用户可以使用 OpenID 登录，并且第 3 方应用程序和服务可以使用 OAuth 对您的网站进行 API 调用并访问用户数据。
听起来您想要在开始后添加到此项目模板中的是让您的用户能够使用用户名+密码以及 OpenID 登录。此外，如果您希望 Facebook 和 Twitter 成为您的用户的一个选项，您也必须实现这一点，因为它们不使用 OpenID 标准。但 DotNetOpenAuth 下载包含使用 Twitter 和 Facebook 登录的示例，因此您可以在那里获得一些指导。
我怀疑你在授权方面不会有太多事情可做。正如我之前所说，它附带 OAuth，这可能足以满足您的需求。
First I'd like to emphasize the difference between authentication and authorization:
A user authenticates to your web site by supplying some credential such as a username+password. OpenID allows this to be displaced by having the user authenticate to another service, which then asserts the user's identity to your web site on the user's behalf. Your site trusts the third party service (the OpenID Provider) and therefore considers the user logged in.
A service or application does not authenticate to your web site -- at least not typically. A user authorizes a service or application to access the user's data. This is typically done by the application requesting authorization of the service provider, then sending the user to the service provider, where the user first authenticates (so the service provider knows who its talking to) and then the user says to the site "yes, it's ok for [application] to access my data [in some restricted way]". From then on, the application uses an authorization token to access the user data on the service provider site. Note that the application does not authenticate itself as if it were the user, but it uses another code to assure the service that it is authorized to access a particular user's data.
So with that distinction clarified, you can make decisions on your site about authentication and authorization completely independently. For instance, if you want your users to be able to log in with all of: username+password, OpenID, and Facebook, you can do that. A completely orthogonal decision is how you authorize applications (there are many protocols you can use for this, OAuth of course being quite popular).
OpenID is focused on user authentication. OAuth is focused on application authorization. However, a few services such as Facebook and Twitter have chosen to use OAuth for authentication and authorization instead of using OpenID for authentication and OAuth for authorization.
Now for your own project, I strongly recommend you check out the ASP.NET MVC 2 OpenID web site (C#) project template available from the VS Gallery. Out of the box it comes with OpenID authentication and OAuth Service Provider support. This means your users can log in with OpenID, and 3rd party applications and services can use OAuth to make API calls to your web site and access user data.
What it sounds like you'd want to add to this project template once you get going is the ability for your users to log in with username+password as well as OpenID. Also, if you want Facebook and Twitter to be an option for your users you must implement that as well since they don't use the OpenID standard. But the DotNetOpenAuth download includes samples for logging in with Twitter and Facebook so you have some guidance there.
I suspect you won't have much if anything to do on the authorization front. It comes with OAuth as I said before, and that will probably suffice for you.
首先。您需要在心里将您的 API 与身份验证方法分开。
您的 API 基本上是资源以及操作这些资源的方法。您可以使用多种方法来验证对 API 的访问。
OAuth 就是这样一种身份验证机制。成为 OAuth 提供商很棒，尽管规范有点难以掌握，尤其是与签名有关的部分。
一旦部署了 OAuth，客户端应用程序通常可以轻松进行身份验证，因为大多数语言都有很多“开源、已经完成、只需实现”的库。
OAuth 的优缺点已经争论了一段时间。但为了形成你自己的观点，我建议阅读这份由 Eran Hammer-Lahav 撰写的权威指南，他是其中一位负责 OAuth 规范。
据我所知，OAuth 的唯一真正替代方案是 OAuth 2.0 和简单的基本身份验证。
除此之外，您正在谈论使用 Open-ID 或 Facebook 身份等进行身份验证。这是您需要问自己的另一个问题。但它确实超出了 API 和 OAuth 的范围。对我来说，这更像是在您的服务中创建用户的问题。我可能错了。
First of all. You need to mentally separate what is your API - from methods of authentication.
Your API is basically resources, and methods to manipulate those resources. And you can have several methods of authenticating access to you API.
OAuth is one such authentication mechanism. Being an OAuth provider is great, even though the specification is a little hard to grasp, especially the parts that have to do with signatures.
Once you have OAuth in place, client applications usually have an easy time authenticating, since there are so many "open source, already done, just implement" libraries available in most languages.
The pros and cons of OAuth have been debated for a while. But to form your own opinion I suggest reading this definitive guide, written by Eran Hammer-Lahav, one of the people responsible for the OAuth specification.
The only real alternatives to OAuth as far as I see it, are OAuth 2.0 and just simple basic authentication.
Other than that, you are talking about authenticating using Open-ID, or facebook identity etc. This is yet another question you need to ask yourself. But it really falls outside the scope of APIs and OAuth. To me, that feels more of a question of user creation in your service. I may be wrong.