背景说明
谈到Identity Server 4，当我考虑客户端应用程序中的用户管理设计时，我遇到了障碍。
此时，我使用ASP身份用户帐户作为其用户存储设置Identity Server。
我已经构建了用于将用户添加到Identity Server用户存储的UI。
我已经测试过设置一个MVC应用程序的客户端，我正处于可以成功通过Identity Server进行身份验证并在我的客户端应用程序中接收openid身份令牌的位置。
Identity Server为我的客户端应用程序提供身份验证。
现在，我需要专注于我的应用程序内的授权。这就是我遇到困难的地方，我需要在应用程序本地创建用户，其中存储了应用程序中的用户权限。
我需要将Identity Server中的用户链接/关联到客户端应用程序中的用户。
一种方法是将sub存储在身份令牌中作为客户端应用程序数据库中的用户声明（Asp Identity）。这样，当用户进行身份验证时，我可以根据令牌中的sub在本地数据库中找到它们。
sub必须是身份服务器用户存储中用户的唯一ID。这样，如果用户的电子邮件被更改，我们仍然可以链接两个用户帐户。
客户端应用程序中的用户帐户不需要密码或电子邮件地址，它将纯粹是用于整个应用程序授权的声明和角色，以及任何其他特定于应用程序的信息。
题
在客户端应用程序中创建用户时，必须存在Identity Server和客户端应用程序之间的通信？
在这个过程中，这些任务应该完成吗？我正在寻找两个应用程序之间的通信流程的一些指导？
编辑
客户端应用程序中根本没有用户帐户是否可行？
这意味着用户的所有用户声明都存储在Identity Server的用户存储中。
当客户端使用IDP进行身份验证时，它仅请求特定于客户端应用程序的用户声明。
用户存储中的示例用户声明： -
当客户端应用程序A进行身份验证时，它仅请求范围clientA_role
这感觉很糟糕！
有什么建议？
如果您有许多客户端应用程序，那么我建议用户管理的方式是：
用户管理服务：
为用户管理创建单独的服务，身份服务器将用作用户存储，并且当需要用户元数据时，应用程序将用作用户存储库。
你也为什么要这样做：
用户存储中的示例用户声明： -
“clientA_role”：“管理员”
“clientB_role”：“用户”
为什么不只是“角色”：“用户”？在您的应用程序中，您将使用授权[角色]注释保护您的资源。
不要为不同的应用程序创建不同的字段，将其视为一般用户管理服务，我很确定标准化您的身份管理将使其更容易，并将获得您的可维护性和灵活性。
IdentityServer服务处理身份管理：
如果您认为您的应用程序没有如此深入的用户管理需求，那么将用户存储保留在提供授权的同一服务中可能是个好主意。
在这种情况下，再次存储标准声明并在id_token或access-token中返回您需要的声明。
更新：
对于在不同应用程序中具有不同角色的特定用户：
让我们说我们有以下几点：
1- User1在第一个app中具有用户角色，在第二个app中具有admin角色
User1.Roles{"FirstAppUser","SecondAppAdmin"}
2- User2在两个应用中都有管理员角色，然后：
User2.Roles{"FirstAppAdmin","SecondAppAdmin"}