IdentityServer，客户端和用户配置文件管理

Question

在您有多个客户端和中央IdentityServer 4 实例处理用户身份验证/ n的情况下，您将如何管理来自各个客户端的用户配置文件？< / p>

当前情况：

1. 用户点击管理个人资料
2. 用户被重定向到IdentityServer上的自定义管理声明页面，a）加载表单中的所有声明，b）允许用户修改此类声明，c）使用新值更新它们
3. 用户被重定向到引荐来源网址（然后检索 这些新的声明通过令牌刷新包括配置文件 范围） - 虽然重定向并不总是可行，或者是皱眉 从设计的角度来看（用户的体验从此被打破 他们被带到不同的地方，设计不同。）

所需方案：

1. 用户点击管理个人资料
2. 用户被重定向到客户端本身的个人资料页面（例如SPA或桌面），填充了个人资料范围中的信息
3. 用户更新配置文件数据，然后客户端对IdentityServer进行API调用以更新用户＆＃39;集中索赔
4. 本地声明已刷新，以反映发送给Identity Server的声明

主要关注点：这在建筑上讲是一种合理的方法吗？用户配置文件（例如名字/姓氏，性别，DoB等）应由IdentityServer管理（通过API或自己的页面），还是应集中存储并由IdentityServer使用/管理（作为声明加载）和个人客户端应用？您将如何处理所需的情景？

我得到的最近信息是方法3 讨论here。

...但它是一个3岁以上的文档，我不确定oidc-client / IdentityServer 4开发者今天推荐的是什么。

任何见解都将受到高度赞赏。

克里斯

Answer 1

我认为需要第二种情况的主要原因可能是

  

带到不同设计的不同位置

是吗？

如果不是，我认为在多个客户端应用上重复相同或类似的声明更新页面没有任何好处，如果有多个。

如果是，并且您无法自定义身份提供商（Identity Server）上的页面，您仍然可以拥有一个声明更新页面，但只能在Identity Server之外托管。此页面（正式地说：托管它的应用程序）将是身份提供者的客户端以及重定向到此处的客户端应用程序。

这种方法的一个好处是，您可以完全控制此页面的外观，事件使其具体取决于客户端。

  

用户配置文件（例如姓/名，性别，DoB等）应由IdentityServer管理（通过API或自己的页面），还是应集中存储并由IdentityServe使用/管理

对此没有单一答案，因为它完全取决于您的实际业务背景。

甚至比你描述的还要糟糕，你可以有一个混合系统，其中一些声明由多个子系统共享，但其他子系统有自己的配置文件不与任何其他子系统共享，所有这些都集成在一个身份提供者周围。