微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

是否可以在ASP.NET 5的Web API中使用外部身份提供程序?

阅读 this question,@ Pinpoint的答案以及对评论的进一步讨论,我很清楚我们原本无法在使用ASP.NET 5开发的应用程序中添加身份提供程序.然后,可以替代传统的OAuthAuthorizationServerMiddleware. AspNet.Security.OpenIdConnect.Server正如我在很多地方发现的那样.

现在,有一点我仍然不确定这一切因为我真的不是安全方面的专家,所以我对OAuth的了解不是很深刻.我怀疑如下:在使用OAuth保护一个RESTful API时是否可以使用外部身份提供程序?

请注意,我不是在谈论将社交登录添加一个网站,我在谈论在一个RESTful API中使用一个外部身份提供程序.

我的观点是,这让我有点困惑,因为我一直认为这应该是我的应用程序的一个问题.

所以我的问题是:在使用OAuth和ASP.NET 5时,是否可以使用外部身份提供程序,而不是实现一个?如果有可能,这简单如何工作?我的意思是,我的应用程序仍然需要能够管理用户的身份,因为它需要管理声明等等.

在这种情况下,如果真的有可能,流程将如何?外部身份提供商应该发行令牌吗?但我的应用程序如何能够验证这些令牌并管理用户身份?

编辑:我不确定的原因之一是,当我们使用USEOAuthAuthentication扩展方法时,我们设置了一个回调路径,描述为

The request path within the application’s base path where the user-agent will be returned. The middleware will process this request when it arrives.

现在,如果我们正在开发一个网站,那么这确实有意义.该人去那里,点击按钮登录Facebook等提供商.用户重定向到Facebook的页面,然后在他登录后,他被重定向到该站点的某个页面.

另一方面,使用RESTful API,这是毫无意义的.没有被重定向的概念.

这使得外部提供程序的使用似乎仅适用于站点,而不适用于RESTful API.这是我的问题的要点.

解决方法

My doubt is the following: is it possible to use an external identity provider when using OAuth to protect one RESTful API?

是的,这绝对是可能的.这正是您使用Azure Active Directory保护API端点时所执行的操作:

app.USEOAuthBearerAuthentication(options => {
    options.AutomaticAuthenticate = true;
    options.Authority = "https://login.windows.net/tushartest.onmicrosoft.com";
    options.Audience = "https://TusharTest.onmicrosoft.com/TodoListService-ManualJwt";
});

一个合理的问题是:如果您可以使用AAD发布的令牌来保护您的API,为什么不能用Facebook或Google令牌做同样的事情?

与Facebook或Google不同,AAD发布名为JWT令牌的完全标准化令牌,OAuth2承载中间件可以“读取”和“验证”以确定令牌是否仍然有效并且是否真的为您的API发放(即,如果受众附带令牌)对应于您的API.您可以在发出授权请求时使用resource参数控制此值.

您无法使用FB或Google令牌执行类似操作,因为它们完全不透明.实际上,这并不奇怪,因为这些令牌只有一个目标:允许您查询FB或Google Api,而不是您自己的(这些社交提供商不允许设置访问令牌的受众).

由于您无法自行阅读令牌,唯一的选择是询问FB或Google是否仍然有效以确保您的API不接受无效令牌.这是你可以(轻松)用Facebook做的事情,因为他们提供了一个“令牌检查端点”,你可以查询它:https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow(参见Inspecting access tokens章节).这样,您可以确保令牌未过期,并确定与令牌对应的用户.

遗憾的是,这种方法有两个缺点:

>您必须对Facebook端点进行额外的HTTP调用以验证访问令牌,这意味着缓存收到的令牌以避免Facebook充斥太多请求.
>由于访问令牌不是针对您自己的API发布的,因此您必须绝对确保将访问令牌发布给您完全信任的客户端应用程序,否则它将允许任何第三方开发人员将您自己的FB / Google令牌与您的API一起使用无需征得用户同意.这显然是一个重大的安全问题.

您可以在本SO答案的最后部分找到更多信息(适用于Katana和DropBox,但您应该明白这一点):OWIN/OAuth2 3rd party login: Authentication from Client App,Authorization from Web API

So my question here is: when using OAuth and ASP.NET 5,is it possible to use an external identity provider,other than implementing one? If it is possible,how this works in short? I mean,my app still needs to be able to manage the identities of users,in the sense that it needs to manage claims and so on.

In that case,if it is really possible,how the flow would be? The external identity provider should issue the tokens? But how my app would be able to verify those tokens and manage users identities?

解决前一部分中提到的限制,最好的选择是 – 正如您已经想到的那样 – 创建自己的授权/身份验证服务器.这样,您的API就不会(直接)接受FB或Google令牌,而是由您自己的服务器发布的令牌,这些令牌可能会将您的用户重定向到FB或Google进行身份验证.

这正是这个样本的作用:https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/tree/vNext/samples/Mvc

>客户端应用程序(Mvc.Client)邀请用户使用您的授权服务器(Mvc.Server)进行身份验证,以便他可以获取访问令牌以便稍后查询API(也在Mvc.Server中).为此,用户将被重定向到您的授权服务器,授权服务器本身可让您通过Google或Twitter进行身份验证.>完成此外部身份验证步骤后,用户将被重定向回授权服务器(Mvc.Server),并要求他同意客户端应用程序(Mvc.Client)访问其个人数据.>当给出同意时,用户将被重定向回客户端应用程序,其中包含可用于查询API端点的访问令牌.

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐