JWT解码在GraphQL网关级还是微服务级?

JWT解码在GraphQL网关级还是微服务级?,jwt,graphql,microservices,Jwt,Graphql,Microservices,我有一个使用GraphQL的微服务架构。它有一个GraphQL网关,它使用模式拼接来组合所有GraphQL模式 我计划按如下方式实施身份验证和授权: 身份验证-令牌由第三方(AWS Cognito)验证 解码-我想在网关级别执行此操作。这是一个巨大的好处。它将消除跨多个微服务的大量逻辑。这也使得迁移变得很容易,以防我们需要更改提供程序(Auth0?)。加上 服务中的授权-所有服务必须管理的是授权和业务逻辑 我在这里遗漏了什么陷阱吗?这可能是一个坏主意吗?这听起来像是一个很好的验证用例,只要所有底

我有一个使用GraphQL的微服务架构。它有一个GraphQL网关,它使用模式拼接来组合所有GraphQL模式

我计划按如下方式实施身份验证和授权:

  • 身份验证-令牌由第三方(AWS Cognito)验证
  • 解码-我想在网关级别执行此操作。这是一个巨大的好处。它将消除跨多个微服务的大量逻辑。这也使得迁移变得很容易,以防我们需要更改提供程序(Auth0?)。加上
  • 服务中的授权-所有服务必须管理的是授权和业务逻辑

  • 我在这里遗漏了什么陷阱吗?这可能是一个坏主意吗?

    这听起来像是一个很好的验证用例,只要所有底层请求都需要一个有效的令牌,它就会被放入网关中。我唯一要提醒的是,不要太聪明地使用你试图推到网关的逻辑,以避免长期耦合。例如,在网关中解码和验证JWTs的签名是一件很好的事情,因为您可能希望对所有路由执行相同的检查,但尝试验证作用域或执行任何每路由检查最好在应用程序本身中处理


    在上下文中,我目前有一个nginx网关在我的服务前检查JWT令牌的签名,然后再将其传递出去,这使基础服务可以假定令牌是可信的,并防止错误请求击中应用程序服务器。

    感谢您的回答!是的,我使用自定义API网关请求授权器来验证令牌,如果路由是公共的,它也允许没有令牌的请求通过。我最终得到了以下体系结构:API网关授权器(验证和验证令牌,让我们来看看没有令牌的请求)>GraphQL网关(将令牌传递给缝合的服务)>远程服务(解码令牌,并管理授权)