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

Question

例如，我有 3 个服务:

认证

卖家

买家

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

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

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

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

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

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

卖方和买方相互影响。

Answer 1

这听起来对我最近解决的问题很熟悉
假设您的服务是基于 HTTP 的，那么我建议您查看 oAuth 2.0
来自 RFC 6749 的简短副本

OAuth addresses these issues by introducing an authorization layerand separating the role of the client from that of the resourceowner. In OAuth, the client requests access to resources controlledby the resource owner and hosted by the resource server, and isissued a different set of credentials than those of the resourceowner.

Instead of using the resource owner's credentials to access protectedresources, the client obtains an access token -- a string denoting aspecific scope, lifetime, and other access attributes. Access tokensare issued to third-party clients by an authorization server with theapproval of the resource owner. The client uses the access token toaccess the protected resources hosted by the resource server.

For example, an end-user (resource owner) can grant a printingservice (client) access to her protected photos stored at a photo-sharing service (resource server), without sharing her username andpassword with the printing service. Instead, she authenticatesdirectly with a server trusted by the photo-sharing service(authorization server), which issues the printing service delegation-specific credentials (access token).

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

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

有证书

授权服务器

拥有和控制用户身份、凭证和声明

控制授予和拒绝对用户资源的访问(在这种情况下并不真正需要)

将用户凭据交换为 access_token，然后客户端可以使用它来访问来自资源提供者的信息

(可选)授予可用于更新过期 access_token

的 refresh_token

资源提供者

有信息的服务

信任授权服务器

验证 access_token 是否有效(未过期、签名正确等)

验证是否存在所需的声明(用户、角色等)

并将信息发布给请求的客户

客户

应用程序(内部或第三方)

通过已知的授权服务器对用户进行身份验证

获取access_token

使用 access_token 调用资源提供者获取信息

声明身份
声明身份 ( explained better in more details here) 不仅仅是用户名和密码，它可以为经过身份验证的用户携带许多声明，例如电子邮件、出生日期等，您可以使用这些声明来传达任何常见的用户属性到您的各种服务。
共享属性
现在，您的最后一个问题是将用户(或身份)链接到每个服务中的实体，该实体代表该服务上下文中的一些唯一信息......这可以通过将现有的经过身份验证的身份和 access_token 链接到内部表示来实现每个服务中的用户。
类似:

卖家是用户

买家就是用户

用户拥有(声明，access_token)

声明是键值对

声明可以是(姓名、电子邮件、角色等)