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

Question

下午你们都

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

前提

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

我正在研究将Kong作为我的API网关或使用AWS API Gateway来封装我的微服务的细节.而且,它感觉很好.

Kong 的JWT插件将验证JWT的签名,然后将customer_id标题中的一行传递给微服务.我还要提一下,我们的第三方开发人员也将参与集成乐趣.这是我看到的事情的基本草图:

履行

1. 为我们拥有的每个平台和第三方开发人员生成"消费者".(网络应用,移动应用,我们有目前的集成合作伙伴注:我不希望为登录的每个用户创建消费者虽然肯定更安全,这增加了大量的工作同样,如果你弄清楚.如何从我的API网关中获取秘密我明显有其他问题)
2. 让孔验证对我的要求.有点像门口的保镖,没有授权,只是认证.
3. 我并不需要知道令牌是有效的,一旦它到达微服务,我可以使用一些中间件将其解码并使用自定义逻辑来决定是否该用户真正应该做的是什么,他们正在试图做的.

额外的东西

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

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

• 在任何地方都使用SSL,JWT存储在Web浏览器中仅限SSL的cookie中,并且在任何声明中都没有存储敏感信息.

多谢你们.

Answer 1

我最近致力于解决这个问题和前提,在AWS架构中将大型整体重构为多个服务.

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

这就是我们如何去做...

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

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

解决方案1:AWS API网关

利弊

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

缺点

1. 流量无法直接路由到内部网络(专用VPC段),这意味着需要额外的网关.
   编辑: Amazon API网关支持与私有VPC的端点集成.谢谢@Red提到这个.
2. 慢,我们的基准测试显示通过API网关的每个请求增加了100-150毫秒的延迟.

解决方案2:孔

利弊

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

缺点

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

履行

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

流

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

其他

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

架构: