使用OAuth保护REST API，同时仍然允许通过第三方OAuth提供商(使用DotNetOpenAuth)进行身份验证
我有一个具有简单REST API的产品，因此该产品的用户可以直接与产品的功能集成，而无需使用我的web用户界面。
最近，我从不同的第三方获得了将他们的桌面客户端与API集成的兴趣，以允许我的产品的用户使用该第三方应用程序访问他们的数据。
我已经看到，希望使用Twitter的应用程序使用Twitter托管的登录页面进行身份验证，该登录页面授予特定应用程序访问该用户数据的权限。单击“允许”或“拒绝”按钮，身份验证过程就完成了。据我所知，Facebook使用的是同样的机制。
根据进一步的研究，这似乎是OAuth的行动，看到我的应用程序接口是基于.Net的，我想我应该使用DotNetOpenAuth并提供类似的机制。不幸的是，这些示例文档很少(如果有的话)，我在网上找到的唯一教程似乎集中在帮助您为您的用户提供登录机制，以便他们可以使用第三方提供商登录到您的网站。
我真正想做的是让REST API处理web应用程序的所有核心身份验证和业务逻辑，并让web应用程序本质上是另一个仅通过OAuth使用API的应用程序。用户可以直接使用用户名和密码在网站上进行身份验证，也可以通过MyOpenID或Facebook等第三方提供商进行身份验证，然后网站将以某种方式使用返回的令牌来针对REST API进行身份验证。
基本上看起来我需要我的应用程序接口来以某种方式托管OAuth服务，但也需要让用户使用第三方OAuth服务。我不禁想，我对OAuth的理解还不够充分，不能决定我是不是把事情搞得过于复杂了，或者我想做的事情是好是坏。
有人能至少给我一个大概的概述吗?我需要采取哪些步骤，或者我应该看些什么才能做到这一点？或者给我指点一些教程？或者抨击我的提议，告诉我我(在架构上)做的都是错的？
回答 2
Stack Overflow用户
发布于 2011-01-05 12:06:14
首先，我想强调身份验证和授权之间的区别：
用户通过提供某些凭据(如username+password )对您的网站进行身份验证。OpenID允许通过让用户向另一个服务进行身份验证来取代这一点，然后该服务代表用户向您的网站断言用户的身份。您的站点信任第三方服务( OpenID提供商)，因此将用户视为已登录。
服务或应用程序不会对您的网站进行身份验证--至少通常不会。用户授权服务或应用程序访问用户的数据。这通常是由应用程序请求服务提供商的授权，然后将用户发送到服务提供商，在那里用户首先进行身份验证(因此服务提供商知道正在与谁交谈)，然后用户对站点说“是的，应用程序以某种受限的方式访问我的数据是可以的”。从那时起，应用程序使用授权令牌来访问服务提供商站点上的用户数据。请注意，应用程序不会像用户一样对自身进行身份验证，但它使用另一个代码来确保服务有权访问特定用户的数据。
因此，澄清了这种区别之后，您就可以在站点上完全独立地做出有关身份验证和授权的决策。例如，如果您希望您的用户能够登录username+password、OpenID和Facebook，您可以做到这一点。一个完全正交的决策是如何授权应用程序(您可以使用许多协议来实现这一点，当然，OAuth非常流行)。
OpenID专注于用户身份验证。OAuth专注于应用程序授权。然而，像Facebook和Twitter这样的一些服务已经选择使用OAuth进行身份验证和授权，而不是使用OpenID进行身份验证，使用OAuth进行授权。
现在，对于您自己的项目，我强烈建议您查看VS库中提供的ASP.NET MVC 2 OpenID web site (C#)项目模板。它具有开箱即用的OpenID身份验证和OAuth服务提供商支持。这意味着您的用户可以使用OpenID登录，第三方应用程序和服务可以使用OAuth调用您的网站并访问用户数据。
听起来，一旦你开始使用这个项目模板，你想要添加的是让你的用户使用username+password和OpenID登录的能力。此外，如果你想让Facebook和Twitter成为你的用户的选择，你也必须实现它，因为他们不使用OpenID标准。但DotNetOpenAuth下载包含了使用Twitter和Facebook登录的示例，因此您可以从中获得一些指导。
我怀疑您在授权方面不会有太多事情可做。正如我之前所说的，它附带了OAuth，这可能足以满足您的需求。
Stack Overflow用户
发布于 2011-01-04 04:05:16
首先。您需要在心理上将什么是API -与身份验证方法分开。
你的API基本上就是资源，以及操纵这些资源的方法。您可以使用多种方法对API的访问进行身份验证。
OAuth就是这样一种认证机制。作为一个OAuth提供者是很棒的，尽管规范有点难以掌握，特别是与签名有关的部分。一旦有了OAuth，客户端应用程序通常就可以轻松地进行身份验证，因为在大多数语言中都有许多“开放源码，已经完成，只需实现”的库。
OAuth的利弊已经争论了一段时间了。但是为了形成您自己的观点，我建议阅读负责OAuth规范的人之一this definitive guide, written by Eran Hammer-Lahav。
据我所知，OAuth唯一真正的替代品是OAuth 2.0和简单的基本身份验证。
除此之外，您正在讨论使用Open-ID或facebook身份等进行身份验证。这是您需要问自己的另一个问题。但它确实超出了API和OAuth的范围。对我来说，这更像是在你的服务中创建用户的问题。我可能错了。
https://stackoverflow.com/questions/4574868
复制相似问题