是否可以在带有 ASP.NET 5 的 Web API 中使用外部身份提供程序? [英] Is it possible to use an external Identity Provider in a Web API with ASP.NET 5?
问题描述
阅读这个问题、@Pinpoint 的回答以及对评论的进一步讨论，我很清楚，我们无法在本机向使用 ASP.NET 5 开发的应用程序添加身份提供程序.然后，AspNet.Security.OpenIdConnect.Server 提供了一种可能的替代旧 OAuthAuthorizationServerMiddleware 的替代品，正如我在许多地方.
现在，有一点我仍然不确定，因为我真的不是安全专家，所以我对 OAuth 的了解不是很深.我的疑问如下:在使用 OAuth 保护一个 RESTful API 时是否可以使用外部身份提供者?
请注意，我不是谈论将社交登录添加到一个网站，我谈论的是在一个 RESTful API 中使用一个外部身份提供者.
我的观点是，这让我有点困惑，因为我一直认为这应该是我的应用程序的关注点.
所以我的问题是:在使用 OAuth 和 ASP.NET 5 时，是否可以使用外部身份提供程序，而不是实现一个?如果可能，简而言之，这是如何工作的?我的意思是，我的应用仍然需要能够管理用户的身份，因为它需要管理声明等.
那样的话，如果真的有可能，流程会怎样?外部身份提供者应该颁发令牌吗?但是我的应用如何能够验证这些令牌并管理用户身份?
我对此感到不确定的原因之一是，当我们使用 UseOAuthAuthentication 扩展方法时，我们设置了一个回调路径，描述为<块引用>
应用程序的基本路径中的请求路径，用户代理将在其中返回.中间件会在请求到达时对其进行处理.
现在，如果我们正在开发一个网站，那么这确实很有意义.这个人去那里，点击一个按钮登录像 Facebook 这样的提供商.用户被重定向到 Facebook 的页面，然后在他登录后，他被重定向到网站的某个页面.
另一方面，对于 RESTful API，这是毫无意义的.没有被重定向的概念.
这使得外部提供程序的使用似乎仅适用于站点，而不适用于 RESTful API.这是我问题的重点.
我的疑问如下:在使用 OAuth 保护一个 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，而不是您自己的 API(这些社交提供商不允许设置访问令牌的受众).
由于您自己无法读取令牌，唯一的选择是询问 FB 或 Google 是否仍然有效，以确保您的 API 不接受无效令牌.这是您可以(轻松)使用 Facebook 做的事情，因为他们提供了令牌检查端点".您可以查询:https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow(请参阅检查访问令牌一章).这样就可以保证token没有过期，确定token对应的用户.
遗憾的是，这种方法有两个缺点:
- 您必须对 Facebook 端点进行额外的 HTTP 调用以验证访问令牌，这意味着缓存收到的令牌以避免过多的请求淹没 Facebook.
- 由于访问令牌不是为您自己的 API 颁发的，您必须绝对确保将访问令牌颁发给您完全信任的客户端应用，否则它将允许任何第三方开发人员使用他自己的 FB/Google 令牌与您的 API，而无需征得用户同意.这显然是一个主要的安全问题.
您可以在此 SO 答案的最后一部分中找到更多信息(它适用于 Katana 和 Dropbox，但您应该明白这一点):OWIN/OAuth2 3rd 方登录:来自客户端应用程序的身份验证，来自 Web API 的授权
<块引用>
所以我的问题是:在使用 OAuth 和 ASP.NET 5 时，是否可以使用外部身份提供程序，而不是实现一个?如果可能，简而言之，这是如何工作的?我的意思是，我的应用仍然需要能够管理用户的身份，因为它需要管理声明等.
那样的话，如果真的有可能，流程会怎样?外部身份提供者应该颁发令牌吗?但是我的应用如何能够验证这些令牌并管理用户身份?
要解决上一部分中提到的限制，最好的选择是 - 正如您已经想到的 - 创建您自己的授权/身份验证服务器.这样，您的 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 端点的访问令牌重定向回客户端应用程序.
Reading this question, @Pinpoint's answer and the further discussion on comments, I'm well aware that natively we can't add an identity provider to our apps developed with ASP.NET 5. One possible replacement for the legacy OAuthAuthorizationServerMiddleware is then provided by the AspNet.Security.OpenIdConnect.Server as I've found in many places.
Now, there is one point that I'm still unsure about all this because I'm really not an expert in security, so my knowledge about OAuth is not very deep. My doubt is the following: is it possible to use an external identity provider when using OAuth to protect one RESTful API?
Notice that I'm not talking about adding social login to one website, I'm talking about using one external identity provider in one RESTful API.
My point is, this makes me a little confused yet, because I always thought this should be a concern of my app.
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?
EDIT: One of the reasons I feel unsure about that is that when we use the UseOAuthAuthentication extension method, we set up one callback path which is described as
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.
Now, if we are developing a site, then this really does make sense. The person goes there, click a button to login with a provider like Facebook. The user is redirected to Facebook's page and then after he logs in, he is redirected to some page of the site.
On the other hand, with a RESTful API this is meaningless. There is no notion of being redirected.
This makes it seems that the usage of external providers is only for sites and not for RESTful API's. This is the main point of my question.
My doubt is the following: is it possible to use an external identity provider when using OAuth to protect one RESTful API?
Yes, it's definitely possible. This is exactly what you do when you use Azure Active Directory to protect your API endpoints:
app.UseOAuthBearerAuthentication(options => {
options.AutomaticAuthenticate = true;
options.Authority = "https://login.windows.net/tushartest.onmicrosoft.com";
options.Audience = "https://TusharTest.onmicrosoft.com/TodoListService-ManualJwt";
});
The next legitimate question is: if you can use the tokens issued by AAD to protect your API, why couldn't you do the same thing with Facebook or Google tokens?
Unlike Facebook or Google, AAD issues completely standardized tokens named JWT tokens that the OAuth2 bearer middleware can "read" and "verify" to determine whether the token is still valid and was really issued for your API (i.e if the audience attached with the token corresponds to your API. You can control this value using the resource parameter when making your authorization request).
You can't do something similar with FB or Google tokens, since they are totally opaque. Actually, it's not really surprising since these tokens have only one objective: allowing you to query FB or Google APIs, not your own ones (these social providers don't allow to set the audience of the access token).
Since you can't read the token yourself, the only option is to ask FB or Google whether it is still valid to make sure your API doesn't accept invalid tokens. That's something you can (easily) do with Facebook as they offer a "token inspection endpoint" you can query for that: https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow (see the Inspecting access tokens chapter). This way, you can ensure the token is not expired and determine the user corresponding to the token.
Sadly, this approach has two downsides:
- You have to make an extra HTTP call to the Facebook endpoint to validate the access token, which implies caching received tokens to avoid flooding Facebook with too many requests.
- As the access token is not issued for your own API, you MUST absolutely ensure that the access token was issued to a client application you fully trust, or it will allow any third party developer to use his own FB/Google tokens with your API without having to request user's consent. This is - obviously - a major security concern.
You can find more information in the last part of this SO answer (it's for Katana and about Dropbox, but you should get the idea): 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?
To work around the limitations mentioned in the previous part, the best option is - as you've already figured out - to create your own authorization/authentication server. This way, your API doesn't (directly) accept FB or Google tokens but the tokens issued by your own server, that can possibly redirect your users to FB or Google for authentication.
This is exactly what this sample does: https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/tree/vNext/samples/Mvc
The user is invited by the client application (Mvc.Client) to authenticate with your authorization server (Mvc.Server) so he can get an access token to later query the API (also in Mvc.Server). For that, the user is redirected to your authorization server, which itself offers you to authenticate with Google or Twitter.
When this external authentication step is done, the user is redirected back to your authorization server (Mvc.Server), where he's asked to give his consent for the client app (Mvc.Client) to access his personal data.
When the consent is given, the user is redirected back to the client application with the access token you can use to query the API endpoint.
这篇关于是否可以在带有 ASP.NET 5 的 Web API 中使用外部身份提供程序?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
