IdentityServer 4 对它的工作原理感到困惑

Question

我一直在阅读和观看很多关于 Identity Server 4 的内容，但我仍然对此感到有些困惑，因为似乎有很多活动部件。

我现在明白这是一个单独的项目，它处理用户身份验证。我仍然不明白的是用户如何注册到它？谁存储用户名/密码？

我打算有这个设置

Reactjs front end 
Asp.net Web Api Core 2
Identity Server

那么它会起作用吗？到目前为止，我看到的所有视频都在讨论如何在内存中用户进行测试，但他们从未谈论过注册它。

我看过一些视频，他们有一个现有的数据库，然后将它与 Identity Server 4 连接起来，它会检查该数据库。然而，当你注册新人时，他们不会谈论你是否开始新鲜甚至在他们的场景中。

编辑

Camilo Terevinto 提出了使用“ASP.NET Core Identity”的观点，我一直在研究它并有一些问题。

我现在对此的理解是这样的

1. 用户来到我的 reactjs 站点并想登录
2. 发送到 Identity Server 4 (IS4) 并输入凭据
3. IS4 查看包含 ASP.NET Core Identity 表的数据库并验证用户
4. 如果一切顺利，那么它会转到 IS4 表并添加它需要的任何内容。
5. 发回用户和令牌。
6. 现在 Reactjs 可以访问我的 web api 并从中获取其他数据。

我的问题是如果用户注册会发生什么。

1. 一个用户来到我的 reactjs 站点并想注册

2. 用户查看我的 html/reactjs 表单并填写它

3. 信息被发送到 webapi 并存储在 ASP.NET Core 标识表中

4. 现在怎么办，我是否必须将用户发送到他们现在必须登录的 IS4？那看起来很糟糕。

   同样在这种情况下，什么会阻止某人通过注册向我的 api 发送垃圾邮件，因为它是一个开放的端点。

Answer 1

谁存储用户名/密码？

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 - Facebook、Google、Microsoft 帐户等）注册和登录用户系统。Microsoft 在 Microsoft Docs 站点中提供了大量信息，请在此处查看介绍。
在这种情况下，将 ASP.NET Core Identity 视为提供用户、角色和声明的 Identity Server 信息的媒介。您通过 Identity 创建用户，但实际的身份验证和授权由 Identity Server 完成。

您可以为您的 React 应用程序公开 REST 端点，以便能够注册（并可能修改？）您的用户及其角色。对于登录，理想的方式是让 React 应用程序通过隐式流程联系身份服务器。

但是，问问自己，在您的场景中是否需要 Identity Server。如果唯一受该 Identity Server 保护的应用程序是 React 应用程序，那么这很可能是一种浪费，您可以单独使用 ASP.NET Core Identity。

关于您的编辑，第一个流程几乎可以，但是：

3. 如果一切顺利，那么它会转到 IS4 表并添加它需要的任何内容。

这一步不会发生。如果一切顺利，IS4 会生成令牌并将其返回。

4. 发回用户和令牌。

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 不同的 URL 的 ClientId，则当 ClientId 受到威胁或为公众所知时，请求将被拒绝以增强安全性，就像 JavaScript Web 客户端的情况一样。