将用户数据存储在身份验证服务器或资源服务器中?或两者? [英] Store user data in auth server or resource server? Or both?
问题描述
这是我第一次使用 IdentityServer 4 和 AspNetIdentity 设置 OpenID Connect，我希望有人能够揭开有关存储用户数据的部分的神秘面纱.
This is my first time setting up OpenID Connect with IdentityServer 4 and AspNetIdentity and I was hoping someone could demystify the part about storing user data.
到目前为止我读到的是用户数据应该存储在连接到身份验证服务器的身份验证数据库中，但我真的很想将用户数据存储在连接到资源的资源数据库中服务器.
What I've read so far is that user data should be stored in the Auth db that is connected to the auth server, but I'd really like to store user data in the resource db too that is connected to the resource server.
我目前有一个如下所示的数据模型:
I currently have a data model that looks like this:
我省略了用户和事件的许多字段，但希望您能了解情况.我们有一个用户表、一个事件表和一个主机表.用户可以主持活动.User 和 Event 之间的多对多关系是通过 Host 表实现的.
I have omitted many of the fields for both User and Event, but you hopefully get the picture. We have a User table, an Event table, and a Host table. A User can Host an Event. The many-to-many relation between a User and an Event is via the Host table.
这是一个关于架构的基本问题，但真的很难找到一个有意义的好答案，这不是一个彻头彻尾的黑客.到目前为止，我已经阅读了来自不同人的以下解决方案:
This is such a rudimentary question on architecture, yet it's really hard to find a good answer that makes sense and that isn't a total hack. So far I've read about the following solutions from different people:
仅将所有用户数据存储在 Auth 数据库中，然后在 Auth 服务器上设置 API，以便资源服务器可以从 Auth 服务器获取数据.
Store all user data in the Auth db, only, and then set an API up on the Auth server so the Resource server can get data from the Auth server.
其他人说不应该将用户的城市或国家等非身份验证相关数据存储在身份验证数据库中.相反，仅在 Auth 服务器中保留与 auth 相关的数据，而在 Resource DB 中保留任何与用户相关的数据.这听起来像两个用户记录需要同步?听起来是个坏主意.
Someone else says that non-auth related data such as a user's city or country should not be stored in the Auth db. Instead keep auth related data in the Auth server only and any user-related data in the Resource DB. This sounds like the two User records need to be in sync? Sounds like a bad idea.
让资源服务器和身份验证服务器成为一个应用程序，以便我们可以在用户、主机和事件之间建立必要的关系.但这似乎违背了使用 OpenID Connect 的全部目的.
Have the Resource server and Auth server be one application so that we can build the necessary relations between User, Host, and Event. But this seems to defeat the whole purpose of using OpenID Connect.
那么这里的标准架构是什么?或者，如果没有一刀切，您将如何存储这些用户数据?
So what is the standard architecture here? Or if there is no one-size-fits all, how would you store this user data?
推荐答案
考虑到关注点分离和单一责任:
With seperation of concerns and single responsibility in mind:
不仅仅是一个用户表.表中的字段仅在上下文中有意义.
There is not just one user table. Fields in a table have only meaning within the context.
一个用户可以有一个谷歌账户来登录，但对于企业来说，这个账户不是你可以联系到员工的.如何在报告中显示不属于上下文的信息?假设您将城市存储在身份上下文中.那么您将如何在报告中显示该信息?您将需要业务环境中的信息.
A user can have a google account to login, but for the business that is not the account where you can reach the employee. And how about showing information on a report that is not part of the context? Suppose you store city in the identity context. Then how are you going to show that information on a report? You'll need the information in the business context.
还要考虑身份上下文是否是存储信息的好地方.因为用户在掌控之中.当用户不同意使用该信息或只是删除帐户时会发生什么?当您想要同步数据时使用什么策略?
Also consider whether the identity context is a good place to store information. Because the user is in control. What happens when the user doesn't give consent for using the information, or simply removes the account? And what strategy to use when you would like to synchronize data?
共享上下文是行不通的.身份是 IdentityServer 的职责，身份上下文应该只包含有关身份的信息，并且只能由 IdentityServer 访问.请注意，IdentityServer 不绑定到一个应用程序.
Sharing contexts is a no go. Identity is the responsibility of IdentityServer, the identity context should only contain information about the identity and is only accessible by the IdentityServer. Please note that IdentityServer is not bound to one app.
您需要在每个上下文中都有一个用户表. 其中信息可能看起来多余但实际上并非如此，因为它是单独上下文的一部分.就像您使用 Google 等提供商登录时一样.然后在身份上下文中创建用户的本地副本.
You'll need a user table in each context. Where information may seem redundant but actually is not, because it is part of the seperate context. Like when you login using a provider like google. Then a local copy of the user is created in the identity context.
但也许您不应该在业务上下文中将其称为用户.因为在业务上下文中没有用户.他们很可能是员工、客户等.他们可以登录，但不一定.并且可能有业务未知的(身份)用户(例如，在多个应用的情况下).
But perhaps you should not refer to it as User in the business context. Because within the business context there are no users. Most likely they are employees, customers, etc. Who can have a login, but not necessarily. And it's possible to have (identity) users that are unkown to the business (e.g. in case of multiple apps).
IdentityServer 是对用户进行身份验证的权限.可以在多个级别上实施授权.您可以创建一个单独的授权服务器(如 policyserver).或更低级别(resource-based)，其中存在用户在person"表中表示用户有权访问资源.
IdentityServer is the authority to authenticate the user. Authorization can be implemented on multiple levels. You can create a seperate authorization server (like policyserver). Or lower level (resource-based), where the existence of a user inside the 'person' table means that the user has access to the resource.
单独上下文的最佳部分是在上下文中您可以在表之间创建关系，而不会干扰其他上下文.如果您愿意，您可以轻松切换到不同的 oidc 提供商.但是一旦你开始混合上下文，就没有回头路了.
The best part of seperate contexts is that within the context you can create relations between tables, without interfering with other contexts. You can easily switch to a different oidc provider, if you'd like. But once you start to mix contexts, there is no way back.
在 oidc 中非常有用的一件事是 sub 声明.只需通过 sub 声明查找用户并使用业务上下文的本地 ID.
The one thing that is very useful in oidc is the sub claim. Simply look up the user by the sub claim and use the local id for the business context.
关于身份上下文中的字段 city 和 country:有多个级别的身份验证，因此您实际上可能需要此上下文中的信息.但是，如果您需要在其他上下文中的信息(例如显示在报告中)，那么应该将其添加到那里(也).
About the fields city and country in the identity context: there are multiple levels of authentication, so you may actually need the information in this context. But if you need the information in another context (e.g. to show on reports) then it should be added there (as well).
这篇关于将用户数据存储在身份验证服务器或资源服务器中?或两者?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
