Authentication 在微服务体系结构中组织授权的最佳实践？

例如，我有3项服务：

• 认证
• 卖方
• 买主

他们每个人都有自己的数据库、模型、服务。。。等

身份验证服务了解用户、用户组、角色、权限并创建令牌

我应该在哪里存储卖家/买家实体？认证服务，还是卖方/买方服务

卖方/买方服务应如何互动以创建新的卖方/买方实体

卖方/买方服务应如何检查权限

卖方和买方实体有一些公共字段：名称、密码、电子邮件…，但它们每个都有自己的附加字段

---

买卖双方相互影响。

这听起来对我最近解决的一个问题很熟悉

假设您的服务是基于HTTP的，那么我建议您签出

来自 OAuth通过引入授权层来解决这些问题 以及将客户机的角色与资源的角色分离 主人。在OAuth中，客户端请求访问受控制的资源 由资源所有者和资源服务器托管，并且 颁发的凭据集与资源的凭据集不同 主人

而不是使用资源所有者的凭据访问受保护的 资源，客户端获得一个访问令牌——一个表示 特定范围、生存期和其他访问属性。访问令牌 由具有的授权服务器颁发给第三方客户端 资源所有者的批准。客户端使用访问令牌来访问 访问由资源服务器承载的受保护资源

例如，最终用户（资源所有者）可以授予打印权限 服务（客户端）访问存储在照片库中的受保护照片- 共享服务（资源服务器），不共享她的用户名和密码 打印服务的密码。相反，她进行了认证 直接使用照片共享服务信任的服务器 （授权服务器），它发出打印服务委派- 特定凭据（访问令牌）

它只是将身份验证和授权建模到

使用者

• 拥有一些数据，因此也称为资源所有者
• 具有凭据

授权服务器

• 拥有并控制用户标识、凭据和声明
• 控制授予和拒绝访问用户资源的权限（在本场景中不需要）
• 将用户的凭据交换为访问令牌，然后客户端可以使用该令牌从资源提供程序访问信息
• （可选）授予可用于续订过期访问\u令牌的刷新\u令牌

资源提供者

• 包含信息的服务
• 信任授权服务器
• 验证访问令牌是否有效（未过期、未正确签名等）
• 验证是否存在所需的索赔（用户、角色等）
• 并向请求的客户端发布信息

客户

• 应用程序（内部或第三方）
• 通过已知的授权服务器对用户进行身份验证
• 获取访问令牌
• 使用access_令牌调用资源提供程序以获取信息

声称身份 Claims Identity（）不仅仅是用户名和密码，对于经过身份验证的用户，它可以包含许多声明，例如电子邮件、出生日期等，并且您可以使用这些声明将任何常见的用户属性传递给各种服务

共享属性 现在，您最后的问题是关于将用户（或身份）链接到每个服务中表示该服务上下文中某些唯一信息的实体。。。这可以通过将现有的认证身份和访问令牌链接到每个服务中用户的内部表示来实现

类似于：

• 卖家就是用户
• 买方就是用户
• 用户拥有（声明、访问权和令牌）
• 声明是一个键值对
• 索赔可以是（姓名、电子邮件、角色等）

---

用户与员工和老板有何不同？用户只是员工和老板的一个普通类别吗？他们有一些共同的字段（电子邮件、电话……），但每个字段都有自己的附加字段。所以我理解问题域，为什么需要老板服务？这似乎有点多余，因为老板也是员工。这只是一个坏例子。让它成为员工和汽车或其他我会更新你的问题，以反映你的评论。我会帮你编辑它，但以不同的方式提供此域服务可能会改变你原来的问题。例如，属于员工的汽车或与员工完全正交的汽车。如果你能说得更清楚，我很乐意回答你的问题。非常有用，谢谢！在用户经过身份验证并持有令牌后，是每个请求都通过某个代理对令牌进行解码，还是每个资源提供者都使用相同的私钥对令牌进行解码？我的意思是，不同的资源提供者（微服务）如何读取解码的令牌？他们是否都知道私钥或某个代理/授权服务解码令牌，然后请求继续到后端解码？@Korenz他们只需要公钥来决定令牌，如果您使用JWT，那么决定令牌非常简单，并且得到许多开源库的支持