使用OAuth保护我的REST API,同时仍允许通过第三方OAuth提供程序进行身份验证(使用DotNetOpenAuth)

Nat*_*ley 138 openid api rest 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没有足够的把握来决定我是否过于复杂化,或者我正在尝试做的事情是好事还是坏事.

有人能给我至少一个我需要采取的步骤的概述,或者我应该考虑做些什么来实现这一目标?或者指点一些教程?或者提出我的建议并告诉我,我(在架构上)这一切都是错的?

And*_*ott 123

首先,我想强调认证和授权之间的区别:

一个用户通过提供一些凭证,如用户名+密码验证到您的网站.OpenID允许用户通过另一个服务进行身份验证来替换它,然后代表用户向您的网站声明用户的身份.您的站点信任第三方服务(OpenID提供程序),因此会考虑用户登录.

一个服务应用程序不验证你的网站-至少不是一般.用户授权服务或应用程序访问用户的数据.这通常由请求服务提供商授权的应用程序完成,然后将用户发送到服务提供商,用户首先进行身份验证(因此服务提供商知道与谁通话),然后用户对网站说"是, [应用程序]可以[以某种限制的方式]访问我的数据".从那时起,应用程序使用授权令牌访问服务提供商站点上的用户数据.需要注意的是,如果它是用户应用程序不进行身份验证本身,而是它使用另一个代码,以确保其被授权访问特定用户的数据服务.

因此,澄清了这一区别,您可以完全独立地在您的网站上做出有关身份验证和授权的决策.例如,如果您希望用户能够使用以下所有内容登录:用户名+密码,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,这可能就足够了.


Jon*_*der 11

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

您的API基本上是资源,以及操纵这些资源的方法.您可以使用多种方法来验证对API的访问权限.

OAuth就是这样一种身份验证机制.作为OAuth提供商是很好的,即使规范有点难以掌握,尤其是与签名有关的部分.一旦你有了OAuth,客户端应用程序通常可以很容易地进行身份验证,因为在大多数语言中都有很多"开源,已经完成,只需实现"的库.

OAuth的优点和缺点已经争论了一段时间.但是为了形成你自己的观点,我建议阅读这本权威指南,由负责OAuth规范的人之一Eran Hammer-Lahav撰写.

就我看来,OAuth唯一真正的替代品是OAuth 2.0和简单的基本身份验证.

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