GraphQL 授权层的复杂性及 Hasura 的解决方案

在构建 GraphQL API 时，授权层的设计至关重要。与传统 REST API 相比，GraphQL 的灵活查询特性使得授权逻辑更为复杂。本文将探讨如何为自定义 GraphQL 服务器构建授权逻辑，并分析其复杂性来源，同时介绍 Hasura 如何通过声明式方法和谓词下推技术简化这一过程。

一、数据建模

数据建模是构建授权系统的基础，它决定了授权规则的设计方式。

示例：一个应用允许用户查看公共数据和私人数据。此时，数据模型需定义表字段及其关系，以便授权系统区分不同访问权限。

二、角色与属性

常用的授权建模方法有两种：

RBAC（基于角色的访问控制）：通过角色定义访问权限。
ABAC（基于属性的访问控制）：根据用户属性、资源属性或环境条件动态决定权限。

通过角色与属性建模，应用程序可以实现灵活的授权规则。

三、嵌套规则

GraphQL 查询通常包含嵌套字段，可能跨越多个数据源，授权逻辑需在所有嵌套层级动态应用。

示例查询：

query {
  用户 {
    id
    名称
    订单 {
      id
      order_total
    }
  }
}

授权规则需同时适用于用户和订单字段，实现复杂且容易出错。

四、性能优化与谓词下推

在自定义 GraphQL 服务器中，授权检查通常在数据获取后进行，可能导致额外的数据处理和性能下降。

谓词下推 是一种优化方法，将授权规则直接应用到数据库查询中。例如，仅查询当前用户的订单数据，从而减少额外处理并提升安全性。

五、为何授权层复杂？

在自定义 GraphQL 中，授权逻辑可能存在多种实现方式：

API 范围授权：在请求级别应用规则。
解析器级授权：在每个解析器中实现授权逻辑。
模式/模型级授权：授权规则依赖于 GraphQL 模式设计。

每个字段都需授权时，解析器级授权会产生大量样板代码；模式级授权更灵活，但设计和实现更复杂。

六、通过上下文构建授权逻辑

GraphQL 通常使用 Context 对象传递身份验证和授权信息。

JWT 令牌验证示例

try {
  if (token) {
    return jwt.verify(token, YOUR_SECRET_KEY);
  }
  return null;
} catch (err) {
  return null;
}

在解析器中使用上下文

users: (parent, args, contextValue) => {
  if (!contextValue.user) return null;
  return ['bob', 'jake'];
};

七、基于模式的授权

对于复杂需求，可在 GraphQL 模式中定义规则。例如，仅允许用户访问自己的数据：

const CanPublishPost = preExecRule(async (context, fieldArgs) => {
  const graphQLResult = await graphql({
    schema: context.schema,
    source: `query post($postId: ID!) {
      post(id: $postId) {
        author { id }
      }
    }`,
    variableValues: { postId: fieldArgs.postId },
  });
  const post = graphQLResult.data?.post;
  return post && post.author.id === context.user?.id;
});