我的产品具有简单的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没有足够的把握来决定我是否过于复杂化，或者我想做的事情是做坏事的好坏 .
有人能给我一个关于我需要采取的步骤的广泛概述，或者我应该考虑做些什么来实现这一目标？或者指点一些教程？或者提出我的提议并告诉我，我（在架构上）这一切都是错的？
2 回答
首先，我想强调认证和授权之间的区别：
用户通过提供某些凭据（例如用户名密码）对您的网站进行身份验证 . OpenID允许通过让用户对另一个服务进行身份验证来替换它，然后另一个服务代表用户's identity to your web site on the user' . 您的站点信任第三方服务（OpenID提供程序），因此会考虑用户登录 .
服务或应用程序不会对您的网站进行身份验证 - 至少通常不会 . 用户授权服务或应用程序访问用户的数据 . 这通常由请求服务提供商授权的应用程序完成，然后将用户发送到服务提供商，用户首先进行身份验证（因此服务提供商知道与谁通话），然后用户对站点"yes, it's ok for [application] to access my data [in some restricted way]"说 . 从那时起，应用程序使用授权令牌访问服务提供商站点上的用户数据 . 请注意，应用程序不会像对待用户那样对自身进行身份验证，但会使用其他代码来确保服务授权其访问特定用户的数据 .
因此，澄清了这一区别，您可以完全独立地在您的网站上做出有关身份验证和授权的决策 . 例如，如果您希望您的用户能够使用以下所有内容登录：用户名密码，OpenID和Facebook，则可以执行此操作 . 一个完全正交的决定是你如何授权应用程序（你可以使用很多协议，OAuth当然很受欢迎） .
OpenID专注于用户身份验证 . OAuth专注于应用程序授权 . 但是，一些服务（如Facebook和Twitter）选择使用OAuth进行身份验证和授权，而不是使用OpenID进行身份验证，使用OAuth进行授权 .
现在，对于您自己的项目，我强烈建议您查看VS Gallery中提供的ASP.NET MVC 2 OpenID web site (C#)项目模板 . 开箱即用，它带有OpenID身份验证和OAuth服务提供商支持 . 这意味着您的用户可以使用OpenID登录，第三方应用程序和服务可以使用OAuth对您的网站进行API调用并访问用户数据 .
一旦你开始，你想要添加到这个项目模板的声音是你的用户使用用户名密码和OpenID登录的能力 . 此外，如果您希望Facebook和Twitter成为您的用户的选项，您必须实现它，因为他们不使用OpenID标准 . 但DotNetOpenAuth下载包含用于登录Twitter和Facebook的示例，因此您可以在那里获得一些指导 .
我怀疑你不会有太多关于授权前线 . 正如我之前所说，它带有OAuth，这可能就足够了 .
首先 . 您需要在精神上区分您的API - 与身份验证方法 .
您的API基本上是资源，以及操纵这些资源的方法 . 您可以使用多种方法来验证对API的访问权限 .
OAuth就是这样一种身份验证机制 . 作为OAuth提供商是很好的，即使规范有点难以掌握，尤其是与签名有关的部分 . 一旦你有了OAuth，客户端应用程序通常很容易进行身份验证，因为在大多数语言中都有很多“开源，已经完成，只需实现”的库 .
OAuth的优缺点已经争论了一段时间 . 但是为了形成自己的观点，我建议阅读this definitive guide, written by Eran Hammer-Lahav，负责OAuth规范的人之一 .
就我看来，OAuth唯一真正的替代品是OAuth 2.0和简单的基本身份验证 .
除此之外，您正在谈论使用Open-ID或Facebook身份等进行身份验证 . 这是您需要问自己的另一个问题 . 但它确实超出了API和OAuth的范围 . 对我来说，这更像是在服务中创建用户的问题 . 我可能错了 .