Oauth 2.0 在使用IdentityServer的多租户解决方案中，多租户的知识应该存在于何处？

我正在积极学习Identity Server，目前正在使用Identity Server 3进行一个新的多租户项目。在仅仅几个星期的开发之后，我就被提前投入到这个项目中，并负责对后端架构进行微调。根据我的研究和项目目前的布局，我不确定它是否正确

目前，有两个主要项目，一个IdentityServer3项目和一个应用程序项目。到目前为止听起来不错

但是，租户和组并不生活在Identity项目中，他们目前生活在应用程序项目中，应用程序项目完全了解租户，并有效地委托Identity Server应该做的一些“身份验证”工作（如我所见）。更重要的是，应用程序项目也有它自己的实体和用户存储，并且在Identity项目和应用程序项目之间有保持用户存储同步的逻辑。当应用程序想要显示配置文件pic或电子邮件时，它会从本地用户存储中检索它，这可能是Identity project用户存储的最新版本

这就是我觉得事情偏离轨道的地方。如果我们将IdentityServer视为真正的“身份验证即服务”，那么身份信息不应该存在于身份项目中吗？这将包括多租户部分？应用程序不应该直接依赖于用户实体，而应该只知道令牌和声明，以这种方式检索用户元数据（如电子邮件的配置文件范围、配置文件pic等），这意味着不需要在项目之间保持两个用户存储“同步”

我的直觉是将所有用户/多租户实体移到Identity Server上，并重构应用程序以依赖令牌/声明，而不是直接使用用户或租户实体。然后引入一些新的作用域来公开我们选择向客户机应用程序公开的少量元数据。我觉得这是一个更“安全第一”的设计，可能会适当地分离关注点，但是我对Identity Server是新手，不确定我是否走上了正确的道路

---

这里有人能告诉我我在这里的想法是否正常，或者可能有错误的想法吗？非常感谢

我会这样做的！绝对正确是的，你的想法是理智的。尽管在某些情况下，在应用程序存储中保留某些身份验证表（如用户）的（只读）副本是合理的，但主要是出于性能原因，或者出于任何原因需要加入应用程序中的该用户表。但是如果可能的话应该避免。太好了，谢谢大家的理智检查！我对我所考虑的方向更有信心。谢谢你抽出时间！您可能需要在应用程序中保留一个用户“存根”。这将用于链接到其他实体，例如审计跟踪、用户所做的事情、他们所拥有的事情等。这意味着您的应用程序不必在用户使用系统时一直点击id服务器来显示用户数据，例如名称。有多少数据以及如何保持同步将取决于您的系统。根据我的经验，我建议如下，应用程序和身份验证的数据库相同。您的应用程序需要更多关于租户和用户的信息，而不是身份验证的信息。认证只关心用户验证、租约配置文件验证和许可证检查（如果认证中需要）。大多数情况下，它们将从您的应用程序中使用。因此，我反对你的做法。授权人的责任不是负责多租户。嗯