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

Question

大家下午，

只是想找人仔细检查我的工作。以下是保护微服务的有效方法吗？

前提

将我们的单体应用程序和单体合作伙伴 API 分解为面向特定业务功能的微服务。它们很可能是在弹性 beantalk 上运行在 docker 容器中的小型 expressjs 应用程序，谁知道呢。他们会住在某个地方:)

我正在考虑将Kong 用作我的 API 网关，或者使用 AWS API 网关来封装我的微服务的详细信息。而且，感觉还不错。

Kong 的 JWT plugin 将验证 JWT 的签名，然后将标头中的 customer_id 传递给微服务。我还应该提到，我们也有第 3 方开发人员，他们也将参与到集成的乐趣中。这是我所看到的情况的基本草图：

实施

1. 为我们拥有的每个平台和第 3 方开发者生成“消费者”。 （Web 应用程序、移动应用程序以及我们目前拥有的集成合作伙伴。注意：我不希望为每个登录的用户创建消费者。虽然肯定更安全，但这会增加很多工作。另外，如果你弄清楚如何从我的 API 网关中获取秘密我显然还有其他问题）
2. 让 Kong 为我验证请求。有点像门口的保镖，没有授权，只有身份验证。
3. 我不需要知道令牌在到达微服务后是否有效，我可以使用一些中间件对其进行解码并使用自定义逻辑来决定该用户是否真的做他们想做的事。

额外的东西

• Kong 有一个不错的访问控制插件。我们的应用程序和移动应用程序将以“上帝”特权运行，但我绝对可以将开发人员锁定在特定的路线和方法上。

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

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

谢谢大家。

Answer 1

我最近致力于解决这个问题和前提，将一个大型单体架构重构为 AWS 架构中的多个服务。

这个问题没有正确、错误或明确的方法。
但是，我们确实实施了与上述问题中描述的解决方案非常相似的解决方案。
我希望这个答案可以为第一次看到这个的人提供一个很好的方向感。

我们就是这样处理的......

API 网关需要什么？

1. 高度可用
2. 安全
3. 高性能
4. 权威
5. 可扩展

解决方案 1：AWS API Gateway

专业人士

1. 高度可用的托管解决方案。
2. 无需担心可扩展性。
3. 支持 SSL 和自定义域。
4. 通过 lambda 和 IAM 获得权威性。
5. 与其他 AWS 服务配合得很好。
6. 支持开箱即用的 API 版本控制。
7. 使用 CloudWatch 轻松监控。

缺点

1. 流量无法直接路由到内部网络（私有 VPC 网段），这意味着需要额外的网关。
   编辑： Amazon API Gateway Supports Endpoint Integrations with Private VPCs. 感谢@Red 提及这一点。
2. 慢，我们的基准测试显示通过 API 网关的每个请求都会增加 100-150 毫秒的延迟。

解决方案 2：Kong

专业人士

1. 可扩展，但需要我们自己实施和管理。
2. 支持 SSL 和自定义域。
3. 通过插件实现权威性，已打包 JWT 和 OAUTH2 解决方案。
4. RESTful API 可轻松与我们的身份验证服务器集成。
5. 可扩展，以防我们需要一些自定义逻辑。
6. 很快，我们的基准测试显示，通过 Kong 的每个请求都会增加 20-30 毫秒的延迟。

缺点

1. 需要我们进行管理（升级、部署、维护）。
2. 为了实现 HA，需要一个额外的端点，以负载平衡器的形式将流量路由到实际的 GW。
   
   

实施

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

流程

1. 客户端根据我们的身份验证服务器进行身份验证。身份验证服务器是 Kong GW 背后的微服务，上游公开。
2. 身份验证服务器为单个客户端创建一个consumer 和一个JWT。
3. 身份验证服务器使用 JWT 回复。
4. 客户端使用 JWT 从 API 请求访问，流量通过 Kong 路由。
5. Kong 验证 JWT 并将请求路由到带有消费者信息的微服务。
6. 微服务响应客户端。

其他

1. 撤销用户访问权限就像删除令牌一样简单。
2. JWT 声明中未存储敏感信息。
3. 所有服务都通过private DNS zone 相互了解。
   
   

架构：