选择 identity 管理解决方案
大多数 Web 应用都支持身份验证，以确保用户是他们声称的身份。 用户可能是个人，也可能是另一个应用。 管理访问权限可确保用户只能查看和修改其有权查看和修改的信息。 例如，最终用户不应有权访问网站的管理部分。 Identity 管理解决方案旨在处理身份验证和授权相关任务的要求。 要详细了解 identity 管理，请参阅什么是 identity 和访问管理？。 有许多适用于 .NET Web 应用的 identity 管理解决方案可用，每个解决方案都有不同的功能和使用/安装要求。 本文对如何选择适当解决方案提供了指导。
使用 ASP.NET Core Identity 进行基本 identity 管理
ASP.NET Core 附带内置身份验证提供程序：ASP.NET Core Identity。 该提供程序包括 API、UI 和后端数据库配置，可支持管理用户标识、存储用户凭据以及授予或撤消权限。 它支持的其他功能包括：
- 外部登录
- 双因素身份验证 (2FA)
- 密码管理
- 帐户锁定和重新激活
- 验证器应用
对于大多数场景，可能只需要此提供程序。
若要了解详细信息，请访问以下链接：
- 阅读 ASP.NET Core 上的 Identity 简介
- 按照教程生成自己的安全 .NET Web 应用：使用 ASP.NET Core Identity 框架保护 .NET Web 应用。
在其他场景中，管理身份验证和 identity 的服务器或服务可能会有所帮助。
确定是否需要 OIDC 服务器
Web 应用需要一种方法来记住历史操作，因为默认情况下，Web 是无状态的。 否则，每次导航到新页面时，用户都必须输入凭据。 用于记住状态的常见解决方案是 Cookie，这是基于浏览器的数据存储机制。 Web 服务器会发送初始 cookie，然后浏览器存储它并随每个请求将它发回。 此操作自动完成，无需开发人员编写任何代码。 Cookie 易于使用并内置在浏览器中，但设计用于单个网站或 Web 域。 ASP.NET Core 中内置的默认解决方案使用基于 cookie 的身份验证。
令牌是具有元数据的容器，这些元数据通过 HTTP 请求标头或正文显式传递。 与 Cookie 相比，令牌的主要优点是它们不与特定应用或域绑定。 相反，令牌通常使用非对称加密进行签名。 例如，OIDC 服务器使用 JSON Web 令牌 (JWT)格式（包括签名）颁发带有 identity 相关信息的令牌。 非对称加密使用私钥和公钥的组合，其中私钥只有签名者知道，而公钥可告知给每一个人。 也可以加密令牌。
由于私钥的存在，已签名的令牌无法遭到篡改。 公钥：
- 使验证令牌成为可能，可确保令牌未更改。
- 保证它是由持有私钥的实体生成的。
使用令牌的主要缺点是，它们需要服务（通常是 OIDC 服务器）来颁发令牌和提供令牌验证。 必须安装、配置和维护该服务。
需要 OIDC 服务器的一个常见原因是，应用程序公开由其他应用使用的基于 Web 的 API。 对于已公开的基于 Web 的 API，客户端 UI（例如单页应用程序 [SPA]、移动客户端和桌面客户端）被视为属于同一应用。 SPA 示例包括 Angular、React 和 Blazor WebAssembly。 如果应用（不是你的 Web 应用）或任何客户端 UI 必须对你的应用进行安全的 API 调用，那么你可能需要使用令牌。 如果你只有客户端 UI，ASP.NET Core Identity 提供了在身份验证期间获取令牌的选项。 由 ASP.NET Core Identity 颁发的身份验证令牌：
- 可供移动客户端和桌面客户端使用。 Cookie 在安全性和简单性方面优于令牌。
- 不适合管理来自第三方应用的访问。
需要 OIDC 服务器的另一个原因是与其他应用共享登录名。 此功能通常称为“单一登录”，它使用户能够：
- 使用 Web 应用的窗体登录一次。
- 使用生成的凭据向其他应用进行身份验证，而无需再次登录或选择其他密码。
为了提供安全且可缩放的解决方案进行单一登录，通常首选 OIDC 服务器。
对于不与其他应用共享登录名的应用，快速保护应用的最简单方法是使用内置的 ASP.NET Core Identity 提供程序。 否则，需要第三方 identity 管理解决方案提供的 OIDC 服务器。 以下列形式提供 OIDC 服务器：
- 在服务器上安装的产品，称为自承载产品。
- 在主机中运行的容器，例如 Docker。
- 集成用来管理 identity 的基于 Web 的服务。
某些解决方案是免费、开源的，而另一些则获得商业许可。 有关可用选项列表，请参阅 identity 管理解决方案。 你所在组织可能已经在使用 identity 提供程序。 在这种情况下，使用现有提供者而不是其他解决方案可能有意义。 所有主要解决方案都提供了文档，指导如何配置 ASP.NET Core 来使用其产品或服务。
断开连接的方案
许多解决方案（例如 Microsoft Entra ID）都基于云，需要 Internet 连接才能正常工作。 如果你的环境不允许 Internet 连接，则你无法使用服务。
ASP.NET Core Identity 在断开连接的情况下能很好地工作，这些情况包括：
- 应用无法访问 Internet。
- 即使 Internet 断开连接，应用仍必须在本地网络上正常运行。
如果在断开连接的场景中需要完整的 OIDC 服务器，请选择以下选项之一：
- 支持你在自己的计算机上安装和运行服务的解决方案。
- 以容器形式在本地运行身份验证服务。
确定存储登录名等用户数据的位置
要考虑的另一个重要因素是存储用户登录数据的位置。 许多开发人员选择外部基于云的服务（例如 Microsoft Entra ID）来管理 identity。 基于云的服务提供商：
- 负责安全地存储数据。
- 使用最新的安全补丁和版本使软件保持最新。
- 符合 privacy 法规。
由于法规、合规性和策略等原因，另一些人倾向于将数据存储在其自己的服务器上。
如果数据存储在服务器上，则很可能需要选择可安装的或基于容器的解决方案。
Identity 与 OIDC 服务器
使用下图可帮助你确定是使用 ASP.NET Core Identity 系统还是 OIDC 服务器进行身份验证和授权：
下表列出了选择 identity 管理解决方案时要考虑的一些事项。
| 功能 | 自承载（基础结构或容器） | 云 |
|---|---|---|
| 应用集成 | 作为库或框架实现的本地解决方案通常可直接集成到你自己的应用中。 基于容器的解决方案需要在 Web 应用与基于容器的服务之间进行切换。 | 基于云的解决方案通常在登录流中的特定点集成，并提供配置来更新 UI，使其与主题匹配，但可用的自定义级别是有限的。 |
| 配置 | 除了设置标识管理方式，自承载解决方案还要求为环境配置软件。 基于容器的解决方案通常提供基于 Web 的 UI 进行配置。 | 基于云的解决方案通常提供基于 Web 的 UI 进行配置。 |
| 自定义 | 自承载解决方案通常高度可自定义，包括基于代码的更改。 尽管容器化解决方案提供扩展性选项，但它们的限制性通常更高。 | 基于云的服务支持自定义，但这通常仅限于基于配置的更改。 |
| 维护 | 已安装的产品需要专用资源，来确保及时应用所有安全补丁并管理升级。 容器的升级和修补过程通常更顺畅，只需安装提供的容器映像即可。 | 由服务提供商来维护他们基于云的解决方案，包括应用所需的补丁并处理升级。 |
| 用户凭据存储 | 由你负责数据治理和违规处理。 | 管理与处理用户凭据和遵守法规相关的风险。 委托给服务提供商。 |
有关可用选项的详细信息，请参阅 ASP.NET Core 的 Identity 管理解决方案。
