谁存储用户名/密码？
Identity Server 的美妙之处在于它不关心。您可以使用数据库、文本文件或 Active Directory。您有责任选择最适合您的用例的选项。
IMO，使用 ASP.NET Core Identity 来管理用户的 CRUD（Identity Server 已经提供了绑定，您可以在他们的演示中看到它是如何完成的）是最简单的方法。如果您之前使用过 ASP.NET Identity，那么您需要添加的只是
services.AddIdentityServer().AddAspNetIdentity<YourUserClass>();
ASP.NET Core Identity 是来自 Microsoft 的可选 ASP.NET Core 成员资格库，允许您使用内部（Windows、数据库）方法和外部（OAuth/OpenId Connect - Faceboook、Google、Microsoft 帐户等）注册和登录用户系统。 Microsoft 在 Microsoft Docs 站点中提供了大量信息，在这里查看介绍 https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity?tabs=visual-studio%2Caspnetcore2x.
在这种情况下，请将 ASP.NET Core Identity 视为提供用户、角色和声明的 Identity Server 信息的媒介。您通过 Identity 创建用户，但实际的身份验证和授权是由 Identity Server 完成的。
您可以为您的 React 应用程序公开 REST 端点，以便能够注册（并且可能修改？）您的用户及其角色。对于登录，理想的方法是让 React 应用程序通过隐式流程联系 Identity Server。
但是，问问自己，您的场景中是否需要 Identity Server。如果该 Identity Server 保护的唯一应用程序是 React 应用程序，那么它很可能是一种浪费，您可以单独使用 ASP.NET Core Identity。
关于您的编辑，第一个流程几乎没问题，但是：
- 如果一切顺利，那么它会进入 IS4 表并添加它需要的任何内容。
这一步不会发生。如果一切正常，IS4 会生成令牌并返回它。
- 发回用户和令牌。
IS4 与任何 OAuth 2.0 或 OpenID Connect 解决方案一样，仅将生成的令牌返回给客户端。不过，令牌本身包含有关用户的信息。
请记住，ASP.NET Core Identity 将托管在与 IS4 相同的应用程序中，并且它们可以轻松（如果您愿意）共享相同的数据库。
对于第二个流程，如果 Identity 与 IS4 位于同一应用程序中，则用户登录非常容易（事实上，这很常见）。如果它们是分开的，您可能必须让 React 应用程序像平常一样调用 IS4。
我说过您可以对 Identity 和 IS4 使用相同的数据库，因为至少对我来说，将所有安全内容（即应用程序和用户）放在一起是有意义的。
用户信息由用户表中的身份给出，他们的“个人资料”数据可以存储为声明（再次使用身份来持久化它们），并且他们的授权信息可以存储为声明或角色。 IS4 会将用户的所有角色映射到单个“角色”声明，因此您可以选择。
正如您所看到的，Identity 充当 IS4 的存储。身份创建并维护数据，IS4 使用数据。
关于登录/注册过程，在 IS4 应用程序中使用这些过程很常见，以便所有客户端都使用相同的视图，并且用户在应用程序之间获得相同的 UX。如果需要的话，甚至可以很容易地根据客户端 ID 提供不同的登录/注册视图。
永远记住，每个想要联系 IS4 的应用程序都需要在 IS4 数据库中注册为客户端，并且需要启用它。如果应用程序使用的 URL 中的 ClientId 与存储在数据库中的 URL 不同，则当 ClientId 被泄露或被公开时，该请求将被拒绝以增强安全性，就像 JavaScript Web 客户端的情况一样。
