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

Question

例如，我有 3 个服务：

• 身份验证
• 卖家
• 买家

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

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

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

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

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

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

卖家和买家相互交流。

Answer 1

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

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

来自RFC 6749 的简短副本

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

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

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

它只是将身份验证和授权建模为一个工作流

一个用户

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

授权服务器

• 拥有和控制用户身份、凭据和声明
• 控制授予和拒绝对用户资源的访问（在这种情况下并不真正需要）
• 将用户的凭据交换为 access_token，然后客户端可以使用它来访问来自资源提供者的信息
• 可选授予可用于更新过期的 access_token 的 refresh_token

资源提供者

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

客户

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

声明身份

声明身份 (explained better in more details here) 不仅是用户名和密码，它还可以为经过身份验证的用户携带许多声明，例如电子邮件、出生日期等，您可以使用这些声明来传达任何信息各种服务的通用用户属性。

共享属性

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

类似：

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