如何将 API 网关与微服务和 JWT 结合使用？
How do I use an API Gateway in conjunction with microservices and JWTs?
大家下午好，
只是想找人仔细检查我的工作。以下是保护微服务的有效方法吗？
前提
将我们的单一应用程序和单一合作伙伴 API 分解为围绕特定业务功能的微服务。他们很可能是小型 expressjs 应用程序 运行 在 docker 容器中，在弹性 beantalk 上，谁知道呢。他们会住在某个地方:)
我正在考虑将 Kong 作为我的 API 网关，或者使用 AWS API 网关来封装我的微服务的细节。还有就是感觉不错。
Kong 的 JWT plugin 将验证 JWT 的签名，然后将 header 中的 customer_id 传递给微服务。我还应该提到，我们有第 3 方开发人员也将参与集成的乐趣。这是我所看到的情况的基本草图：
实施
- 为我们拥有的每个平台和第 3 方开发人员生成“消费者”。 （Web 应用程序、移动应用程序和我们当前的集成合作伙伴。注意：我不打算为每个登录的用户创建消费者。虽然这肯定更安全，但会增加很多工作。另外，如果你弄清楚如何从我的 API 网关中获取秘密我显然还有其他问题）
- 让孔帮我验证一下请求。有点像门口的保镖，没有授权，只有身份验证。
- 我不需要知道令牌到达微服务后是否有效，我可以使用一些中间件对其进行解码并使用自定义逻辑来确定该用户是否真的 应该做他们想做的事。
额外内容
Kong 有一个不错的访问控制插件。我们的应用程序和移动应用程序将 运行 具有“上帝”特权，但我绝对可以将开发人员锁定在特定的路线和方法上。
撤销第 3 方访问权限很容易，撤销最终用户访问权限不会那么简单，除非我愿意通过生成一个新的秘密来立即使所有 JWT 失效。或许我可以将令牌时间限制在 10 分钟左右，让我们的应用程序检查它们是否已过期、获取新令牌，然后继续处理原始请求。这样我就可以在数据库或其他东西中“标记”它们，而不让生成 JWT。
到处都使用 SSL，JWT 存储在 Web 浏览器中的仅 SSL cookie 中，并且任何声明中都没有存储敏感信息。
谢谢大家。
我最近致力于解决这个问题和前提，将一个大型整体重构为 AWS 架构中的多个服务。
这个问题没有正确、错误或明确的如何。
但是，我们确实实施了一个与上述问题中描述的解决方案非常相似的解决方案。
我希望这个答案可以为第一次看这个的人提供一个很好的方向感。
这就是我们的处理方式...
我们需要 API 网关做什么？
- 高可用性
- 安全
- 高效
- 权威
- 可扩展
解决方案 1：AWS API Gateway
优点
- 高可用性托管解决方案。
- 无需担心可扩展性。
- 支持 SSL 和自定义域。
- 通过 lambda 和 IAM 授权。
- 与其他 AWS 服务配合得很好。
- 支持 API 开箱即用的版本控制。
- 使用 CloudWatch 轻松监控。
缺点
流量无法直接路由到内部网络（私有 VPC 网段），这意味着需要额外的网关。
编辑：
Amazon API Gateway Supports Endpoint Integrations with Private VPCs. 感谢@Red 提到这一点。- 慢，我们的基准测试显示通过 API 网关的每个请求增加了 100-150 毫秒的延迟。
解决方案 2：Kong
优点
- 可扩展，但需要在我们这边实施和管理。
- 支持 SSL 和自定义域。
- 通过插件授权，已经封装了JWT和OAUTH2的解决方案
- RESTful API 以便与我们的身份验证服务器轻松集成。
- 可扩展，以防我们需要一些自定义逻辑。
- 很快，我们的基准测试表明通过 Kong 的每个请求都会增加 20-30 毫秒的延迟。
缺点
- 需要我们进行管理（升级、部署、维护）。
- 为了实现 HA，需要一个额外的端点，以负载均衡器的形式将流量路由到实际的 GW。
实施
我们决定和Kong一起去。
托管解决方案的主要问题是无法将流量路由到我们的专用网络，我们还托管了一个专用 DNS 区域。
此外，Kong 的可扩展性允许我们创建具有与我们的解决方案相关的逻辑的 custom plugins。
我们使用 ALB 在不同 AZ 中的多个 Kong 实例之间进行轮询，以实现冗余和高可用性。
API 配置保存在 Postgres RDS 上，它也是内部和多 AZ。
流量
- 客户端通过我们的身份验证服务器进行身份验证。认证服务器是Kong GW背后的一个微服务，上游是公开暴露的。
- 身份验证服务器为单个客户端创建 consumer with a JWT。
- 身份验证服务器使用 JWT 回复。
- 客户端请求使用 JWT 从 API 访问，流量通过 Kong 路由。
- Kong 验证 JWT 并将请求路由到包含消费者信息的微服务。
- 微服务响应客户端
其他
- 撤销用户访问权限就像删除令牌一样简单。
- JWT 声明中未存储任何敏感信息。
- 所有服务都通过 private DNS zone 相互了解。
架构：
大家下午好，
只是想找人仔细检查我的工作。以下是保护微服务的有效方法吗？
前提
将我们的单一应用程序和单一合作伙伴 API 分解为围绕特定业务功能的微服务。他们很可能是小型 expressjs 应用程序 运行 在 docker 容器中，在弹性 beantalk 上，谁知道呢。他们会住在某个地方:)
我正在考虑将 Kong 作为我的 API 网关，或者使用 AWS API 网关来封装我的微服务的细节。还有就是感觉不错。
Kong 的 JWT plugin 将验证 JWT 的签名，然后将 header 中的 customer_id 传递给微服务。我还应该提到，我们有第 3 方开发人员也将参与集成的乐趣。这是我所看到的情况的基本草图：
实施
- 为我们拥有的每个平台和第 3 方开发人员生成“消费者”。 （Web 应用程序、移动应用程序和我们当前的集成合作伙伴。注意：我不打算为每个登录的用户创建消费者。虽然这肯定更安全，但会增加很多工作。另外，如果你弄清楚如何从我的 API 网关中获取秘密我显然还有其他问题）
- 让孔帮我验证一下请求。有点像门口的保镖，没有授权，只有身份验证。
- 我不需要知道令牌到达微服务后是否有效，我可以使用一些中间件对其进行解码并使用自定义逻辑来确定该用户是否真的 应该做他们想做的事。
额外内容
Kong 有一个不错的访问控制插件。我们的应用程序和移动应用程序将 运行 具有“上帝”特权，但我绝对可以将开发人员锁定在特定的路线和方法上。
撤销第 3 方访问权限很容易，撤销最终用户访问权限不会那么简单，除非我愿意通过生成一个新的秘密来立即使所有 JWT 失效。或许我可以将令牌时间限制在 10 分钟左右，让我们的应用程序检查它们是否已过期、获取新令牌，然后继续处理原始请求。这样我就可以在数据库或其他东西中“标记”它们，而不让生成 JWT。
到处都使用 SSL，JWT 存储在 Web 浏览器中的仅 SSL cookie 中，并且任何声明中都没有存储敏感信息。
谢谢大家。
我最近致力于解决这个问题和前提，将一个大型整体重构为 AWS 架构中的多个服务。
这个问题没有正确、错误或明确的如何。
但是，我们确实实施了一个与上述问题中描述的解决方案非常相似的解决方案。
我希望这个答案可以为第一次看这个的人提供一个很好的方向感。
这就是我们的处理方式...
我们需要 API 网关做什么？
- 高可用性
- 安全
- 高效
- 权威
- 可扩展
解决方案 1：AWS API Gateway
优点
- 高可用性托管解决方案。
- 无需担心可扩展性。
- 支持 SSL 和自定义域。
- 通过 lambda 和 IAM 授权。
- 与其他 AWS 服务配合得很好。
- 支持 API 开箱即用的版本控制。
- 使用 CloudWatch 轻松监控。
缺点
流量无法直接路由到内部网络（私有 VPC 网段），这意味着需要额外的网关。
编辑： Amazon API Gateway Supports Endpoint Integrations with Private VPCs. 感谢@Red 提到这一点。- 慢，我们的基准测试显示通过 API 网关的每个请求增加了 100-150 毫秒的延迟。
解决方案 2：Kong
优点
- 可扩展，但需要在我们这边实施和管理。
- 支持 SSL 和自定义域。
- 通过插件授权，已经封装了JWT和OAUTH2的解决方案
- RESTful API 以便与我们的身份验证服务器轻松集成。
- 可扩展，以防我们需要一些自定义逻辑。
- 很快，我们的基准测试表明通过 Kong 的每个请求都会增加 20-30 毫秒的延迟。
缺点
- 需要我们进行管理（升级、部署、维护）。
- 为了实现 HA，需要一个额外的端点，以负载均衡器的形式将流量路由到实际的 GW。
实施
我们决定和Kong一起去。
托管解决方案的主要问题是无法将流量路由到我们的专用网络，我们还托管了一个专用 DNS 区域。
此外，Kong 的可扩展性允许我们创建具有与我们的解决方案相关的逻辑的 custom plugins。
我们使用 ALB 在不同 AZ 中的多个 Kong 实例之间进行轮询，以实现冗余和高可用性。
API 配置保存在 Postgres RDS 上，它也是内部和多 AZ。
流量
- 客户端通过我们的身份验证服务器进行身份验证。认证服务器是Kong GW背后的一个微服务，上游是公开暴露的。
- 身份验证服务器为单个客户端创建 consumer with a JWT。
- 身份验证服务器使用 JWT 回复。
- 客户端请求使用 JWT 从 API 访问，流量通过 Kong 路由。
- Kong 验证 JWT 并将请求路由到包含消费者信息的微服务。
- 微服务响应客户端
其他
- 撤销用户访问权限就像删除令牌一样简单。
- JWT 声明中未存储任何敏感信息。
- 所有服务都通过 private DNS zone 相互了解。
架构：