在微服务架构中组织授权的最佳实践？

Question

例如，我有3项服务：

• 身份验证
• 卖方
• 买家

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

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

我应该在哪里存储卖家/买家实体？在身份验证服务上，还是在卖家/买家服务上？

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

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

卖方和买方实体有一些共同的字段：名称，密码，电子邮件......，但每个字段都有自己的附加字段。

卖方和买方互相交流。

Answer 1

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

假设您的服务是基于HTTP的，那么我建议您查看oAuth 2.0

来自RFC 6749

的简短副本

  

OAuth通过引入授权层来解决这些问题      并将客户端的角色与资源的角色分开      所有者。在OAuth中，客户端请求访问受控资源      由资源所有者和资源服务器托管，是      发布了一组不同于资源的凭据      所有者。

     

而不是使用资源所有者的凭据来访问受保护的      资源，客户端获取访问令牌 - 表示a的字符串      特定范围，生命周期和其他访问属性。访问令牌      授权服务器向第三方客户端发布      资源所有者的批准。客户端使用访问令牌      访问资源服务器托管的受保护资源。

     

例如，最终用户（资源所有者）可以授予打印      服务（客户）访问存储在照片中的受保护照片 -      共享服务（资源服务器），而不共享她的用户名和      密码与打印服务。相反，她进行身份验证      直接与照片共享服务信任的服务器      （授权服务器），发布打印服务委托 -      特定凭证（访问令牌）。

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

之间的工作流程中

用户

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

授权服务器

• 拥有并控制用户身份，凭据和声明
• 控制授予＆amp;拒绝访问用户的资源（在此方案中并非真正需要）
• 交换用户的凭据以获取access_token，然后客户可以使用该凭据从资源提供者访问信息
• （可选）授予可用于续订过期access_token的refresh_token

资源提供者

• 有信息的服务
• 信任授权服务器
• 验证access_token是否有效（未过期，正确签名等）
• 验证所需的声明是否存在（用户，角色等）
• 并向请求客户发布信息

客户端（一个或多个）

• 申请表（内部或第三方）
• 通过已知授权服务器验证用户
• 获得access_token
• 使用access_token来调用资源提供程序以获取信息

声明身份

声明身份（explained better in more details here）不仅仅是一个用户名＆amp;密码，它可以为经过身份验证的用户提供许多声明，如电子邮件，出生日期等，您可以使用这些声明将任何常见的用户属性传达给您的各种服务。

共享属性

现在，您的最后一个问题是关于将用户（或身份）链接到每个服务中的实体，该实体代表该服务的上下文中的某些独特信息......这可以通过链接现有的身份验证身份来实现和access_token到每个服务中用户的内部表示。

类似：

• 卖方是用户
• 买方是用户
• 用户有（Claims，access_token）
• 声明是键值对
• 索赔可以是（姓名，电子邮件，角色等）