我有一个使用GraphQL的微服务体系结构。它有一个GraphQL网关，它使用模式缝合来组合所有GraphQL模式。
我计划按如下方式实现身份验证和授权：
- 身份验证-令牌由第三方验证(AWS Cognito(
- 解码-我想在网关级别进行解码。这是一个巨大的好处。它将消除多个微服务之间的大量逻辑。这也使迁移变得容易，以防我们需要更改提供程序(Auth0？(。Plus
- 服务中的授权-所有服务都必须管理授权和业务逻辑
这里有我遗漏的陷阱吗？这会是个坏主意吗？
这听起来是一个很好的验证用例，只要所有底层请求实际上都需要一个有效的令牌。我唯一要提醒的是，不要太聪明地使用你试图推到网关以避免长期耦合的逻辑。例如，在网关中解码和验证JWT的签名是一件很棒的事情，因为您可能希望对所有路由执行相同的检查，但尝试验证作用域或执行任何每个路由的检查最好在应用程序本身中处理。
就上下文而言，我目前在我的服务前面有一个nginx网关，在传递JWT令牌之前，它会检查JWT令牌的签名，这样底层服务就可以假设令牌是可信的，并防止坏请求攻击应用程序服务器。