asp.net - IdentityServer、客户端和用户配置文件管理

Question

如果您有多个客户端和一个处理用户身份验证的中央 IdentityServer 4 实例，您将如何管理各个客户端的用户配置文件？

当前情况:

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

期望的场景:

1. 用户点击“管理个人资料”
2. 用户被重定向到客户端本身(例如 SPA 或桌面)上的个人资料页面，其中填充了个人资料范围中的信息
3. 用户更新个人资料数据，然后客户端对 IdentityServer 进行 API 调用以集中更新用户的声明
4. 刷新本地声明以反射(reflect)发送到 Identity Server 的声明

主要关注点:从架构上来说，这是一种合理的方法吗？用户配置文件(例如名字/姓氏、性别、DoB 等)是否应该由 IdentityServer(通过 API 或自己的页面)管理，还是应该集中存储并由 IdentityServer(作为声明加载)和个人客户端应用程序？您将如何处理所需的场景？

我得到的最接近的信息是在方法3中讨论的here .

...但是这是一个 3 年多前的文档，我不确定 oidc-client/IdentityServer 4 开发人员今天推荐什么。

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

克里斯

Answer 1

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

taken to a different location with different design

是吗？

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

如果是，并且您无法在身份提供商(身份服务器)上自定义页面，您仍然可以拥有单个声明更新页面，但只是托管在身份服务器外部。此页面(正式名称:托管该页面的应用程序)将是身份提供商的客户端以及重定向至此处的客户端应用程序。

这种方法的一个好处是，您可以完全控制该页面的外观，事件使其根据客户的情况而定。

Should user profiles (e.g. first/last name, gender, DoB, etc...) be managed by IdentityServer (via an API or own pages) or should these be stored centrally and used/managed by both IdentityServe

这个问题没有单一的答案，因为这完全取决于您的实际业务背景。

这比您描述的更糟糕，您可以拥有一个混合系统，其中一些声明由多个子系统共享，但其他子系统有自己的配置文件，不与任何其他子系统共享，并且所有这些都围绕一个身份提供商集成。