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

Question

例如，我有3个服务：

• 认证
• 卖家
• 买家

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

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

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

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

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

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

卖家和买家互动。

Answer 1

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

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

来自 RFC 6749

的简短副本

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

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

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

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

用户

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

授权服务器

• 拥有并控制用户身份、凭证和声明
• 控制授予和拒绝对用户资源的访问权限（在此场景中并非真正需要）
• 将用户的凭据交换为 access_token，然后客户端可以使用该 access_token 来访问资源提供者的信息
• 可选地授予可用于续订过期的access_token的refresh_token

资源提供者

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

客户

• 申请（内部或第三方）
• 通过已知的授权服务器对用户进行身份验证
• 获取access_token
• 使用access_token调用资源提供者获取信息

索赔身份

声明身份（在此处详细解释）不仅仅是用户名和密码，它可以为经过身份验证的用户携带许多声明，例如电子邮件、出生日期等，并且您可以使用这些声明将任何常见的用户属性传达给您的各种服务。

共享属性

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

类似：

• 卖家也是用户
• 买家就是用户
• 用户拥有（声明、access_token）
• Claim 是一个键值对
• 声明可以是（姓名、电子邮件、角色……等）

Answer 2

最新的解决方案是使用细粒度授权。 https://zanzibar.academy/

您的卖家和买家服务会将有关权限的数据发送到您的身份验证服务。然后，这两个服务会询问身份验证服务“用户 X 对资源 Z 是否有权限 Y？”