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

Question

下午你们，

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

前提

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

我正在考虑将Kong作为我的API网关或使用AWS API Gateway来封装我的微服务的详细信息。而且，它感觉很好。

Kong的JWT plugin将验证JWT的签名，然后将标题中的customer_id传递给微服务。我还要提一下，我们的第三方开发人员也将参与集成乐趣。这是我发生的事情的基本草图：

实施

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

额外的东西

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

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

• SSL无处不在，JWT存储在Web浏览器中仅限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. 很快，我们的基准测试表明，通过孔的每个请求都增加了20-30毫秒的延迟。

<强>缺点

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

实施

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

<强>流量

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

其他

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

<强>架构：