architecture - 如何管理受身份服务器保护的 API 的站点特定配置文件数据

Question

我们有一个新的 Web 项目，我们决定使用 identityserver 作为集中的身份管理服务。从长远来看，我们可以将其他项目迁移到此并将用户维护在一个地方。

该站点本身由一个 angular SPA(客户端)、一个 web api 后端(api 资源)和一个运行身份服务器的单独 aspnet 核心 MVC 站点组成。

用户遵循 openid 连接流程，从前端重定向到身份服务器进行登录，然后使用生成的访问 token 连接到 API。

所有这些都工作正常，我们可以从访问 token 中使用 API 中的基本用户数据，例如主题、电子邮件、姓名等。

到目前为止，还好。

问题是我们有一些特定于应用程序的附加配置文件数据 - 在原始设计中(没有身份服务器)，这些数据都包含在单个 JWT 中，因此很容易从前端、后端或通过内置使用中间件，如 ASP.net 身份。

我们的解决方法是，客户端必须在登录后调用 API，以从包含特定于此问题域的配置文件数据的 API 中检索单独的 token - 例如用户在此系统中拥有的权限和角色。

这最后一步对我来说有点笨拙。例如，我们现在不能在 API 中使用 ASPNET 标识来获取角色，因为它们位于第二个 token 中而不是访问 token 中。

是否有任何最佳实践或方法来处理这种情况？

例如我们应该让身份服务器在登录时从 API 请求配置文件数据，还是因为身份服务器不应该了解客户端的机制而这样做很糟糕？

Answer 1

有趣的问题。我相信在这种情况下我会使用“单一责任主体”。我会质疑谁有能力“响应能力”来提供配置文件数据。如果它是您的应用程序，那么您正朝着正确的方向从 API 本身获取配置文件信息。如果它在身份提供者的能力范围内，那么请继续实现身份提供者。架构是关于决策的，一个好的架构可以让你轻松地改变这些决策，因此，如果配置文件仅适用于该应用程序，则将其保留在该应用程序中。希望这是有道理的。