使用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的掌握不足，无法决定我是否使事情变得过于复杂，或者我试图做的事是做事的好坏。

有人可以至少给我提供我需要采取的步骤的广泛概述，或者我应该怎么看才能实现这一目标？还是让我指点一些教程？还是高估我的建议，并告诉我我正在（架构上）解决所有错误？

首先，我想强调一下身份验证和授权之间的区别：

一个用户验证到您的网站通过提供一些凭证，如用户名+密码。OpenID允许通过使用户向另一个服务进行身份验证来取代此身份，该服务然后代表用户向您的网站声明用户的身份。您的站点信任第三方服务（OpenID Provider），因此将用户视为已登录。

一个服务或应用程序不验证你的网站-至少不是一般。用户授权服务或应用程序访问用户的数据。通常，这是通过应用程序请求服务提供商的授权来完成的，然后将用户发送到服务提供商，在此用户首先进行身份验证（这样服务提供商就知道与谁通话），然后用户对站点说“是的， [应用程序]以某种受限方式访问我的数据是可以的”。从那时起，应用程序使用授权令牌访问服务提供商站点上的用户数据。请注意，应用程序不会像用户一样对自己进行身份验证，但是会使用其他代码来确保服务已被授权访问特定用户的数据。

因此，有了明确的区别，您就可以完全独立地在站点上做出有关身份验证和授权的决策。例如，如果您希望用户能够使用以下所有帐户登录：username + password，OpenID和Facebook，则可以这样做。一个完全正交的决定是如何授权应用程序（可以为此使用许多协议，OAuth当然很受欢迎）。

OpenID专注于用户身份验证。OAuth专注于应用程序授权。但是，一些服务（例如Facebook和Twitter）选择使用OAuth进行身份验证和授权，而不是使用OpenID进行身份验证和OAuth进行授权。

现在，对于您自己的项目，强烈建议您查看VS Gallery中提供的ASP.NET MVC 2 OpenID网站（C＃）项目模板。开箱即用，具有OpenID身份验证和 OAuth服务提供商支持。这意味着您的用户可以使用OpenID登录，并且第三方应用程序和服务可以使用OAuth对您的网站进行API调用并访问用户数据。

听起来像是要立即添加到该项目模板的功能，是用户可以使用用户名+密码以及OpenID登录的功能。另外，如果您希望Facebook和Twitter成为用户的选择，则还必须实现这一点，因为他们不使用OpenID标准。但是DotNetOpenAuth下载包含用于通过Twitter和Facebook登录的示例，因此您可以在那里找到一些指导。

我怀疑您在授权方面没有什么可以做的。就像我之前说过的那样，它附带了OAuth，这可能就足够了。

首先。您需要在精神上将您的API与身份验证方法区分开。

您的API基本上是资源，是操作这些资源的方法。您可以通过多种方法来验证对API的访问。

OAuth是一种这样的身份验证机制。即使很难理解规范，尤其是与签名有关的部分，成为OAuth提供者也很棒。有了OAuth之后，客户端应用程序通常就可以轻松进行身份验证，因为大多数语言都提供了许多可用的“开源，已经实现，只需实现”库。

OAuth的优缺点已经争论了一段时间。但是要形成您自己的意见，我建议您阅读这份权威指南，该指南由负责OAuth规范的人之一Eran Hammer-Lahav撰写。

据我所知，OAuth的唯一真正替代品是OAuth 2.0和简单的基本身份验证。

除此之外，您正在谈论使用Open-ID或Facebook身份验证等。这是您还需要问自己一个问题。但这确实超出了API和OAuth的范围。对我来说，这更像是服务中用户创建的问题。我可能是错的。