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

Question

阅读this question ，@Pinpoint 的回答以及评论的进一步讨论，我很清楚，我们本身无法将身份提供程序添加到使用 ASP.NET 5 开发的应用程序中。然后，AspNet 提供了一种可能的旧 OAuthAuthorizationServerMiddleware 替代方案。 Security.OpenIdConnect.Server 我在很多地方都找到了。

现在，有一点我对这一切仍然不确定，因为我确实不是安全方面的专家，所以我对 OAuth 的了解不是很深。我的疑问如下:在使用 OAuth 保护一个 RESTful API 时是否可以使用外部身份提供商？

请注意，我不是谈论向一个网站添加社交登录，我谈论的是在一个 RESTful API 中使用一个外部身份提供商.

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

所以我的问题是:当使用 OAuth 和 ASP.NET 5 时，除了实现一个之外，是否可以使用外部身份提供程序？如果可能的话，简而言之这是如何运作的？我的意思是，我的应用程序仍然需要能够管理用户的身份，从某种意义上说，它需要管理声明等。

那么，如果真的可以的话，流程会是怎样呢？外部身份提供商应该发行 token 吗？但是我的应用程序如何能够验证这些 token 并管理用户身份？

编辑:我对此感到不确定的原因之一是，当我们使用 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。这是我问题的要点。

Answer 1

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 颁发的 token 来保护您的 API，为什么不能使用 Facebook 或 Google token 做同样的事情？

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

你不能用 FB 或 Google 代币做类似的事情，因为它们是完全不透明的。实际上，这并不奇怪，因为这些 token 只有一个目标:允许您查询 FB 或 Google API，而不是您自己的 API(这些社交提供商不允许设置访问 token 的受众)。

由于您自己无法读取 token ，唯一的选择是询问 FB 或 Google 它是否仍然有效，以确保您的 API 不接受无效 token 。您可以(轻松)使用 Facebook 做到这一点，因为他们提供了一个“ token 检查端点”，您可以查询:https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow (请参阅检查访问 token 章节)。这样可以保证token没有过期，并确定该token对应的用户。

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

• 您必须对 Facebook 端点进行额外的 HTTP 调用来验证访问 token ，这意味着缓存收到的 token 以避免过多的请求淹没 Facebook。
• 由于访问 token 不是为您自己的 API 颁发的，您必须绝对确保将访问 token 颁发给您完全信任的客户端应用程序，否则将允许任何第三方开发者使用他自己的 FB/Google token 与您的 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 token ，而是接受您自己的服务器颁发的 token ，这可能会将您的用户重定向到 FB 或 Google 进行身份验证。

这正是此示例的作用:https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/tree/vNext/samples/Mvc

• 客户端应用程序 (Mvc.Client) 邀请用户向您的授权服务器 (Mvc.Server) 进行身份验证，以便他可以获得访问 token 以稍后查询 API(也在 Mvc.Server 中)。为此，用户将被重定向到您的授权服务器，该服务器本身可以让您通过 Google 或 Twitter 进行身份验证。

• 完成此外部身份验证步骤后，用户将被重定向回您的授权服务器 (Mvc.Server)，系统会要求用户同意客户端应用 (Mvc.Client) 访问其个人数据.

• 获得同意后，用户将被重定向回客户端应用程序，并带有可用于查询 API 端点的访问 token 。