ASP.NET Core 8 中身份验证的改进

ASP.NET Core 团队正在改进 .NET 8 中的身份验证、授权和身份管理(统称为“身份验证”)。新的 APIs 将使自定义用户登录和身份管理体验变得更加容易。新的端点将在没有外部依赖的单页应用程序(SPA)中启用基于令牌的身份验证和授权。我们还将改进我们的指引和文档，使发现和实施身份管理解决方案更加容易。

背景

在 ASP.NET Core 应用程序中启用身份验证的开发人员面临着多种选择：

ASP.NET Core 提供了内置的 ASP.NET Core Identity 解决方案来管理用户登录和授权。
Azure Active directory (Azure AD) 是 Azure 云托管的解决方案，提供细粒度访问控制，并支持高级场景，如“由应用程序代表用户”为 APIs 授权资源。
以包、容器和云服务的形式提供各种第三方解决方案。

ASP.NET Core Identity 是我们独立的开箱即用的解决方案。它包括:

Identity Manager 提供用于处理用户(包括声明和登录)和角色的 APIs。
Identity Store 接口用于持久化标识信息(用户、声明、登录提供者和角色)。
关系数据库身份存储的默认实现。您可以选择创建自己的身份存储的自定义实现。
身份验证系统(SignInManager)。
用户管理界面(Identity UI)。

目前，在 SPA 应用程序中使用 ASP.NET Core Identity 存在一些限制。传统的自定义身份相关页面的方式会迫使你的应用程序回归到服务器渲染的网页。我们依靠外部（第三方）包来支持基于令牌的身份验证。

我们已经听到了您的反馈，并正在研究一种解决方案，以支持更多的没有外部依赖项的即用场景。这使你可以灵活地马上开始使用一个解决方案，同时保持选择其他选项的自由。我们最近在 GitHub 上分享了我们的身份验证计划，得到了很多正面反馈，感谢有机会与这样一个支持我们的社区合作。

IdentityServer 和 SPA 模板

为了处理客户反馈，提供更多的选项并尽可能地简化，我们计划从 .NET 8 中的 SPA 模板中移除对 Duende 的 IdentityServer 的依赖。

作为背景，我们开始发布 IdentityServer4 以支持单页应用程序(SPA)中的 JSON Web Token(JWT)安全性，作为.NET Core 3.1 中 Angular、React 和 Blazor WebAssembly 模板的一部分。该项目当时是开源的。2020年，IdentityServer 项目维护者创建了 Duende，以支持他们努力发展 IdentityServer 并将其更改为商业许可。出于多种原因，我们选择在我们的模板中继续提供 IdentityServer，并在我们的模板中明确了许可要求。

对于自托管符合标准的 Open ID Connect 和 OAuth 2.0 解决方案来说，IdentityServer 仍然是一个绝佳的选择。Duende 提供了他们自己的模板与 ASP.NET Core Identity 集成。除了 IdentityServer (如果您符合社区版的条件，它仍然是免费的)之外，还有许多其他自托管选项可用，包括开源的 OpenIddict 项目和基于容器的 Keycloak。

我们相信这一改变将为您的应用程序选择正确的身份管理解决方案提供更多自由。

为了让您能更轻松地发现可用选项并从中进行选择，我们的模板将链接到一个文档页面，以阐明您的选择。该文档将列出并链接到模板、教程或示例，使您能够添加身份验证，无论是通过我们自己的服务（例如 Azure AD）还是第三方产品（例如 Duende 的 IdentityServer）。

改进自托管解决方案的身份验证

许多用户不希望或不需要维护 OAuth/OpenID Connect 服务器的复杂性和开销。您的应用程序只需要能够通过登录验证用户身份并根据权限安全访问资源。自发布以来，ASP.NET Core 身份平台就内置了对基于角色的访问和简单身份管理的支持。当您在我们的模板中选择“个人帐户”选项进行身份验证或在命令行上使用 dotnet new 的 --auth 选项时，将启用自托管身份管理。您还可以在没有身份的现有项目中搭建身份脚手架。Visual Studio 将构建所需代码以生成和维护用户数据库并通过角色管理登录和权限。ASP.NET Core Identity 提供了一种开箱即用的基于 cookie 的身份验证体验。

我们听取了您的反馈，并确定了 ASP.NET Core 8 中需要改进的两个方面:

▌扩展现有的基于 cookie 的身份验证，以支持 SPA 应用程序中的自定义

基于 cookie 的身份验证适用于较小的单域解决方案。要自定义体验，您必须覆盖我们用于呈现身份管理 UI 的默认服务器呈现的身份页面。当客户从单页 web 应用程序体验过渡到服务器呈现的体验时，这会导致不一致的体验。该团队将添加 API 端点，使开发人员能够在自定义 UI 中使用单页应用程序体验。

▌使现有身份现代化以支持基于令牌的身份验证

React、Angular 和 Blazor WebAssembly 等 SPA 应用程序框架的应用和功能不断增长。尽管我们现有的基于 cookie 的解决方案有效，但行业已经发展了，如今基于令牌的身份验证解决方案更加灵活，而这正是支持身份验证的 SPA 应用程序所需要的。我们有许多用户需要一个不需要第三方依赖项或许可的简单解决方案。我们计划扩展现有的身份平台以启用基于令牌的身份验证。这将主要反映现有基于 cookie 的解决方案的能力和功能，并将身份验证数据封装在令牌而不是 cookie 中，并使其能够在 cookie 不是最佳或不合适的情况下工作。

值得注意的是，SPA 相关的增强针对的是在单个域上运行的解决方案，并且不需要对云资源或第三方 APIs 进行身份验证。对于有这些需求的应用程序，Azure AD、IdentityServer 或其他第三方解决方案是首选。

更容易探索和学习

我们现有的文档涵盖了像 ASP.NET Core Identity、Microsoft Identity 平台和 Azure AD 等功能。大多数的现有文档侧重于产品、技术和功能。.NET 8 的目标是让您有一个单一的起点来学习 .NET Auth 文档的可用选项，它整合了支持教程和示例的链接，更重要的是提供了具体的指导。例如，与具有数据库后端、第三方安全 API 依赖项和社交登录的业务应用程序相比，没有外部依赖项的独立 SPA 应用程序具有不同的需求。我们将与客户合作，确定常见的场景，如“保护现有 API 端点”，并提供涵盖这些需求的端到端文档。

与此同时，Microsoft Entra 正在与 .NET 团队进行密切合作，不仅提供了更好的文档和示例，而且还改进了客户端、SDKs 和工具，以减少将 Azure AD 成功添加到应用程序所需的步骤、代码、配置和概念。