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

Question

例如,我有3个服务:

• 认证
• 卖家
• 买方

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

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

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

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

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

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

卖方和买方互相交流.

Answer 1

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

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

RFC 6749的简短副本

OAuth通过引入授权层并将客户端的角色与资源所有者的角色分开来解决这些问题.在OAuth中,客户端请求访问由资源所有者控制并由资源服务器托管的资源,并且颁发与资源所有者不同的凭据集.

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

例如,最终用户(资源所有者)可以授权打印服务(客户端)访问存储在照片共享服务(资源服务器)中的受保护照片,而无需与打印服务共享其用户名和密码.相反,她直接使用照片共享服务(授权服务器)信任的服务器进行身份验证,该服务器发出打印服务委托特定凭证(访问令牌).

它只是将身份验证和授权建模到工作流之间

一个用户

• 拥有一些数据,因此它也被称为资源所有者
• 有凭证吗？

授权服务器

• 拥有并控制用户身份,凭据和声明
• 控制授予和拒绝用户资源的访问权限(在此方案中不是真的需要)
• 交换用户的凭证以获取access_token,然后客户可以使用该凭据从资源提供者访问信息
• (可选)授予可用于续订过期access_token的refresh_token

资源提供者

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

客户端(S)

• 申请表(内部或第三方)
• 通过已知授权服务器对用户进行身份验证
• 获得access_token
• 使用access_token调用资源提供程序以获取信息

索赔身份

声明身份(此处更详细解释)不仅仅是用户名和密码,它可以为经过身份验证的用户提供许多声明,如电子邮件,出生日期等,您可以使用这些声明进行任何通信各种服务的常见用户属性.

共享属性

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

就像是:

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