从 ASP.NET Core MVC 项目提供 Angular SPA 时，我可以使用 OIDC 混合流吗？

Posted 2023-02-16

【中文标题】从 ASP.NET Core MVC 项目提供 Angular SPA 时，我可以使用 OIDC 混合流吗？

【英文标题】：Can I use OIDC Hybrid Flow While Serving Angular SPA from ASP.NET Core MVC Project?

【发布时间】：2019-06-17 12:31:10

【问题描述】：

我有 2 个不同的 .NET Core 2.2 MVC 项目。我将 IdentityServer4 用于令牌服务器，将 Azure B2C 用于身份存储。

第一个 MVC 应用程序是一个普通的 MVC 应用程序，我已经让它与 OIDC 混合流程完美配合。

第二个 MVC 应用程序是一个 Angular 7 cli 应用程序，它提供 index.html 并包含应用程序将调用的 API。 Angular 应用不会直接调用任何其他 API（网关模式）。

我的问题是关于第二个应用程序的 - 我正在尝试找出设置 Angular 应用程序以确保安全的最佳方法。

我的理解是：OIDC 隐式流暴露暴露了浏览器上的访问令牌。 OIDC 混合流不暴露访问令牌（至少在访问同一个 Web 服务器时 - 没有 CORS），因为 Web 服务器（客户端）使用反向通道通过授权码获取访问令牌，并且它从未暴露给浏览器。

问题 #1：我对隐式与混合的理解是否正确？

如果我的理解是正确的，我认为即使对于 Angular 应用程序来说，最好的方法是混合流，但我看到的大多数使用 OIDC 和 Angular 的示例都涉及隐式流，并且不采用授权码/反向通道的优势。避免在浏览器上使用访问令牌似乎是一件大事，是一个有价值的目标，但想知道为什么它似乎没有完成？

问题 #2：我正在从我的 MVC 服务器提供我的 Angular index.html - 为什么我不能只使用混合流来保护 index.html 页面，并将令牌保留在反向通道上？

有些事情告诉我，我对这一切的理解并不完全......

【问题讨论】：

在浏览器场景中，您通常会使用隐式，否则您需要将客户端密码公开给 Web 应用程序，您当然不应该这样做。通常，访问令牌应该在短时间内有效，从而限制被盗令牌可能造成的损害。

【参考方案1】：

你的理解是正确的。您可以保护您的index.html。您将面临的唯一问题是它不是今天的默认配置。根据您的要求，很可能您根本不需要任何 oidc 客户端库，您可以使用 (same-site, http-only) cookie（不是承载令牌）保护您的（唯一）API，并在您的 Angular 防护中确保您仍然登录到您的后台（如果没有，通过本地 MVC 资源重定向以将服务器端代码纳入登录过程）。

请参阅this question，尤其是下面的 cmets 和链接以供进一步参考。