例如，我有3个服务：
认证方式
卖方
买方
他们每个人都有自己的数据库，模型，服务等
身份验证服务了解用户，用户组，角色，权限并创建令牌。
我应该在哪里存储卖方/买方实体？使用身份验证服务还是使用卖方/买方服务？
卖方/买方服务应如何相互作用以创建新的卖方/买方实体？
卖方/买方服务应如何检查权限？
卖方和买方实体有一些共同的字段：名称，密码，电子邮件...，但每个实体都有自己的其他字段。
卖方和买方彼此交互。
最佳答案
这听起来像是我最近正在解决的一个问题
假设您的服务基于HTTP，那么我建议您签出oAuth 2.0
RFC 6749的简短副本
OAuth通过引入授权层解决了这些问题
并将客户的角色与资源的角色分开
所有者。在OAuth中，客户端请求访问受控资源
由资源所有者并由资源服务器托管，并且是
发出的凭证集与资源的凭证集不同
所有者。
而不是使用资源所有者的凭证来访问受保护的
资源，客户端获得访问令牌-表示字符串的字符串
具体范围，生存期和其他访问属性。访问令牌
由授权服务器向第三方客户端颁发
资源所有者的批准。客户端使用访问令牌
访问资源服务器托管的受保护资源。
例如，最终用户（资源所有者）可以授予打印权
服务（客户端）访问其存储在照片中的受保护照片-
共享服务（资源服务器），而不共享她的用户名和
打印服务的密码。相反，她进行身份验证
直接通过照片共享服务信任的服务器
（授权服务器），它发出打印服务委托-
特定凭证（访问令牌）。
它只是将身份验证和授权建模为
用户
拥有一些数据，因此也称为资源所有者
有凭证
授权服务器
拥有并控制用户身份，凭证和声明
控制授予和拒绝对用户资源的访问权限（在这种情况下并不需要）
将用户的凭证交换为access_token，客户端随后可以使用该凭证来访问来自资源提供者的信息
（可选）授予一个refresh_token，可用于续订过期的access_token
资源提供者
有信息的服务
信任授权服务器
确认access_token有效（尚未过期，未正确签名等）
验证是否存在必需的声明（用户，角色等）
并将信息发布给发出请求的客户
客户
申请书（内部或第三方）
通过已知的授权服务器对用户进行身份验证
获得一个access_token
使用access_token调用资源提供者以获得信息
声明身份
声明身份（explained better in more details here）不仅是用户名和密码，它还可以包含许多已认证用户的声明，例如电子邮件，生日等，并且您可以使用这些声明来传达任何常见的用户属性为您的各种服务。
共享属性
现在，您的最后一个问题是将用户（或身份）链接到每个服务中的实体，该实体表示该服务上下文中的一些唯一信息...这可以通过将现有的经过身份验证的身份和access_token链接到的内部表示来实现。每个服务中的用户。
就像是：
卖方是用户
买家是用户
用户拥有（声明，access_token）
索赔是关键值对
声明可以是（姓名，电子邮件，角色等）