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

Posted 2023-02-19

【中文标题】在微服务架构中组织授权的最佳实践？

【英文标题】：Best practice to organize authorization in microservice architecture?

【发布时间】：2016-05-24 16:45:39

【问题描述】：

例如，我有 3 个服务：

身份验证 卖家 买家

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

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

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

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

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

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

卖家和买家相互交流。

【问题讨论】：

用户与员工和老板有何不同？用户只是员工和老板的通用类别吗？

他们有一些共同的领域（电子邮件，电话......），但他们每个人也有自己的附加领域

我才明白问题域，为什么需要boss服务？因为老板也是雇员，所以这似乎有点多余。

这只是一个糟糕的例子。让它成为员工和汽车或其他东西

我会更新您的问题以反映您的评论。我会帮助您编辑它，但以不同方式提供此域服务可能会改变您最初的问题。例如，属于员工的汽车或与员工完全正交的汽车。如果您能用更清晰的方式做到这一点，我很乐意尝试回答您的问题。

【参考方案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 是一个键值对 声明可以是（姓名、电子邮件、角色等）

【讨论】：

非常有用，谢谢！在用户通过身份验证并持有令牌后，是每个请求都通过某个代理来解码令牌，还是在每个资源提供者上使用相同的私钥进行解码？我的意思是，不同的资源提供者（微服务）如何读取解码的令牌？他们是否都知道私钥或某些代理/授权服务解码令牌并且请求继续到后端解码？

@Korenz 他们只需要公钥来决定令牌，如果您使用的是 JWT，那么决定令牌非常容易，并且得到许多开源库的支持