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

Question

例如，我有3个服务：

• 身份验证
• 卖方
• 买家

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

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

我应该把买卖双方的实体放在哪里？关于认证服务，还是关于买卖双方的服务？

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

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

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

买卖双方相互作用。

Answer 1

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

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

一份来自RFC 6749的短拷贝

OAuth通过引入授权层并将客户端的角色与资源所有者的角色分离来解决这些问题。在OAuth中，客户端请求访问由资源所有者控制并由资源服务器承载的资源，并获得与资源所有者不同的凭据集。客户端不使用资源所有者的凭据访问受保护的资源，而是获得一个访问令牌--表示特定范围、生存期和其他访问属性的字符串。经资源所有者批准，授权服务器向第三方客户端颁发访问令牌。客户端使用访问令牌访问资源服务器承载的受保护资源。例如，最终用户(资源所有者)可以授权打印服务(客户端)访问存储在照片共享服务(资源服务器)中的受保护照片，而无需与打印服务共享她的用户名和密码。相反，她直接使用照片共享服务(授权服务器)信任的服务器进行身份验证，该服务器颁发打印服务委托专用凭据(访问令牌)。

它简单地将身份验证和授权建模到

用户

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

授权服务器

• 拥有并控制用户标识、凭据和声明。
• 授予和拒绝对用户资源的访问的控件(在此场景中不是真正需要的)
• 将用户的凭据交换为access_token，然后客户端可以使用该从资源提供者访问信息
• 可选地授予可用于更新过期的refresh_token的access_token。

资源提供者

• 有信息的服务
• 信任授权服务器
• 验证access_token是否有效(未过期、签名正确等)
• 确认是否存在所需的索赔(用户、角色等)
• 并向请求的客户端发布信息。

客户

• 申请书(内部或第三方)
• 通过已知的授权服务器验证用户。
• 获得一个access_token
• 使用access_token调用资源提供程序以获取信息

索赔身份

索赔标识(在这里更详细的解释)不仅仅是用户名和密码，它还可以为经过身份验证的用户携带许多声明，如电子邮件、出生日期等，您可以使用这些声明将任何公共用户属性传递给您的各种服务。

共享属性

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

，类似于：

• 卖方是用户。
• 买方是用户。
• 用户拥有(索赔，access_token)
• 声明是一个键值对。
• 索赔可以是(姓名，电子邮件，角色，.等)