如何将API网关与微服务和JWT结合使用？

大家下午好

我只是想找个人仔细检查一下我的工作。以下是确保微服务安全的有效方法吗

前提 将我们的单片应用程序和单片合作伙伴API分解为面向特定业务功能的微服务。它们很可能是运行在docker容器中的小型expressjs应用程序，运行在elastic beanstalk上，谁知道呢。他们将住在某处：）

我正在考虑作为我的API网关站起来，或者使用AWSAPI网关封装我的微服务的细节。而且，感觉很好

for Kong将验证JWT的签名，然后将标题中的

客户id

传递给microservice。我还应该提到，我们有第三方开发人员也将参与集成乐趣。以下是我所看到的情况的基本示意图：

实施

为我们拥有的每个平台和第三方开发人员生成“消费者”。（Web应用程序、移动应用程序和我们现有的集成合作伙伴。注意：我不希望为每个登录的用户创建消费者。虽然肯定更安全，但这会增加很多工作。此外，如果你知道如何从我的API网关中获取秘密，我显然还有其他问题）

让孔为我核实一下请求。有点像门口的保镖，没有授权，只有认证

我不需要知道令牌在到达微服务后是否有效，我可以使用一些中间件对其进行解码，并使用自定义逻辑来决定该用户是否真的应该做他们想做的事情

额外的东西

• 香港有一个很好的访问控制插件。我们的应用程序和移动应用程序将以“上帝”的权限运行，但我肯定可以将开发人员锁定在特定的路径和方法上

• 撤销第三方访问将很容易，撤销最终用户访问将不会这么简单，除非我愿意通过生成一个新的秘密一次使所有JWT无效。也许我可以将令牌时间限制在10分钟左右，让我们的应用程序检查它们是否过期，获取新令牌，然后继续原始请求。这样，我可以在数据库或其他地方“标记”它们，而不让JWT生成

• SSL无处不在，JWT存储在web浏览器中仅SSL的cookie中，任何声明中都没有存储敏感信息

---

谢谢大家。

我最近致力于解决这个问题和前提，在AWS体系结构中将一个巨大的整体重构为多个服务

如何回答这个问题没有正确、错误或明确的答案。
但是，我们确实实现了一个与上述问题中描述的非常类似的解决方案。
我希望这个答案能给第一次看到这个的人一个很好的方向感

我们就是这样做的

我们需要从API网关获得什么？

高度可用

稳妥

性能

权威的

可伸缩

解决方案1： 专业人士

高可用的托管解决方案

不需要担心可伸缩性

支持SSL和自定义域

通过lambda和IAM获得权威

与其他AWS服务配合良好

支持开箱即用的API版本控制

使用CloudWatch轻松监控

缺点

流量不能直接路由到内部网络（专用VPC段），这意味着需要额外的网关。
编辑： 谢谢@Red提到这一点

我们的基准测试显示，通过API网关的每个请求都增加了100-150毫秒的延迟

解决方案2： 专业人士

可扩展，但需要在我们端实施和管理

支持SSL和自定义域

权威的插件，JWT和OAUTH2的解决方案已经打包

RESTful API便于与我们的身份验证服务器集成

可扩展，以防我们需要一些自定义逻辑

我们的基准测试显示，通过Kong的每个请求都增加了20-30毫秒的延迟

缺点

需要我们端的管理（升级、部署、维护）

为了实现HA，需要一个额外的端点，以负载平衡器的形式将流量路由到实际的GW。

实施 我们决定和香港一起去。
托管解决方案的主要问题是无法将流量路由到我们的专用网络，在那里我们还托管一个专用DNS区域。
此外，Kong的可扩展性使我们能够创建与我们的解决方案相关的逻辑。
为了实现冗余和高可用性，我们在不同AZ中的多个Kong实例之间进行循环
API配置保存在Postgres RDS上，该RDS也是内部和多AZ

流量

客户端根据我们的身份验证服务器进行身份验证。认证服务器是香港GW背后的一个微服务，具有公开的上游

身份验证服务器为单个客户端创建带有的

身份验证服务器使用JWT进行回复

客户端通过JWT请求API访问，流量通过香港路由

Kong验证JWT并将请求发送到micro服务，并提供有关消费者的信息

微服务响应客户端

其他

---

撤销用户访问权与删除令牌一样简单

JWT索赔中未存储任何敏感信息

所有服务都通过网络相互了解。

模式：

---

我想你可以在香港前面用ELB代替ALB。将www.example.com/api/*映射到该E