微服务架构已成为实现解决方案的首选架构，因为它具有可伸缩性，逻辑和物理分离，管理部分功能的小型团队，技术灵活性等优点，因此赢得了广泛的应用。但是由于微服务是分布式的，因此管理它们的复杂性增加。
关键挑战之一是如何在微服务中实现身份验证和授权，以便我们可以管理安全性和访问控制。
在本文中，我们将尝试探索一些可用的方法，并了解如何实现它们。
我们可以遵循三种方法：

本地身份验证和授权（微服务负责身份验证和授权） - 优点

  1.   - 可以为每个微服务实现不同的身份验证机制。
  2.   - 授权可以更细化
  • 缺点
    • 代码变得越来越庞大。
    • 每个服务使用不同身份验证的可能性非常低，因此代码会重复。
    • 开发人员需要知道权限矩阵，并且应该了解每个权限将要执行的操作。
    • 犯错的可能性很高。 全局身份验证和授权（ - 优点
    • 身份验证和授权，因此无需重复代码。
    • 将来更改身份验证机制很容易，因为只有一个地方可以更改代码。
    • 微服务的代码非常轻巧，仅关注业务逻辑。
  • 缺点
    • 微服务无法控制用户能否访问什么，因此无法授予更高级别的权限。
    • 故障是集中的，将导致一切停止工作。 全局身份验证和授权是微服务的一部分 - 优点
    • 细粒度的对象权限是可能的，因为微服务可以决定将看到或不看到的用户。
    • 全局身份验证将更容易管理，减轻负载。
    • 由于授权是由相应的微服务控制的，因此没有网络延迟，而且速度会更快。
    • 没有授权的集中式故障。
  • 缺点
    • 供开发人员编写的代码略多，因为他们必须专注于权限控制。
    • 需要一些努力来了解您可以使用每个权限执行的操作。

在我看来，第三个选择是最好的选择，因为大多数应用程序具有通用的身份验证机制，因此全局身份验证非常有意义。可以从多个应用程序和客户端访问微服务，它们可能有不同的数据需求，因此全局授权成为限制每个应用程序可查看内容的因素。通过本地授权，微服务可以确保仅授权客户端应用程序查看其需要查看的内容。
我的组织在我们最近从事的项目之一中实施了相同的方法。我们构建了一个身份验证服务，该服务主要负责与LDAP系统集成以验证用户，然后联系RBAC（基于角色的访问控制）服务以根据用户在用户上下文中扮演的角色来填充权限矩阵。例如，同一用户可以是一个应用程序中的普通用户，而另一个可以是管理员。因此，我们需要了解用户进入的上下文，并且RBAC是解码上下文并填充相关权限集的地方。然后，将权限矩阵作为JWT令牌中声明的一部分发送到微服务。微服务仅适用于那些权限，并返回需要返回的内容。
【20201123】微服务中的身份验证和授权 - 图1
认证和授权的架构流程

结论

上述解决方案是全局身份验证，微服务根据传递给它的权限来控制其内容的授权，这是在微服务开发中处理身份验证和授权模块的可能解决方案之一。此外，我们可以通过在服务网格类型的体系结构中构建边车来增强此解决方案，在此我们将授权转移到边车上。