GraphQL 服务器中的授权 [英] Authorization in GraphQL servers

问题描述

如何在 GraphQL 服务器中处理授权?

How to handle Authorization in GraphQL servers?

我是否应该在每个请求的 Authentication 标头中传递 JWT 令牌并在 resolve() 之后检查授权用户，并在每个 query 上检查用户的角色和 mutation

Shall I pass the JWT token in the Authentication header of every requests and check for the authorized user after resolve() and check for the role of user on every query and mutation

推荐答案

简介

首先，如您所说的，身份验证的常用方法是使用包含发出请求的用户的 ID 的签名 JWT.

Introduction

First of all, a common approach for authentication as you state is using a signed JWT that contains the id of the user making the request.

现在让我们看看在考虑给定请求的授权时可以使用的不同参数.

Now let's have a look at the different parameters we can use when considering the authorization of a given request.

• 谁提出请求?

由上面提到的用户 id 决定.可以在数据库中查找有关请求者的更多信息，例如关联的用户角色.这意味着如果我们使用 SQL，我们需要维护一个 User 表，并在注册时将新用户添加到该表中.

determined by the user id mentioned above. More information about the requester like associated user roles can be looked up in the database. This means that we need to maintain a User table if we are using SQL for example, and add new users to this table on registration.

应该执行哪个操作?

用户可能被授予只读访问权限.某些更改或查询仅允许某些用户使用.

users might be granted read-only access. Certain mutations or queries are only allowed for certain users.

查询/变异响应中包含哪些字段?

某些字段只能由某些用户访问.

some fields should be only accessed by certain users.

考虑到这些信息，我们可以想出不同的权限系统.最常见的是，在这样的系统中，默认情况下不允许任何操作.当请求进来时，可以将上述参数与现有权限进行匹配，如果找到匹配的权限，则授予该请求.

With this information in mind, we can come up with different permission systems. Most commonly, in such a system, no operation is allowed by default. When a request comes in, the parameters mentioned above can be matched with the existing permissions and if a matching permission is found, the request is granted.

在某些应用程序中，基于角色的方法非常有效.例如，对于更简单的 Stack Overflow 版本，我们可以拥有角色 EVERYONE、AUTHENTICATED 和 MODERATOR.一个合理的权限规则可能是这样的:

In certain applications, a role-based approach works great. For example, for a simpler version of Stack Overflow, we could have the roles EVERYONE, AUTHENTICATED and MODERATOR. A sensible permission rule could be this:

• 每个人都可以阅读问题/答案
  • 请求者:无所谓(每个人)
  • 操作:allQuestions、allAnswers 查询
  • 字段:text
  • EVERYONE can read questions/answers
    • requester: doesn't matter (everyone)
    • operations: allQuestions, allAnswers queries
    • fields: text

    其他规则(不包括参数):* AUTHENTICATED 用户可以创建新的问题/答案* MODERATOR 用户可以创建新的问题/答案* MODERATOR 用户可以删除问题/答案.

    Other rules (leaving parameters out): * AUTHENTICATED users can create new questions/answers * MODERATOR users can create new questions/answers * MODERATOR users can delete questions/answers.

    现在，例如，如果一个未经身份验证的请求请求 allQuestions 查询，那很好，因为我们找到了允许它的权限(第一个).

    Now for example, if a non-authenticated requests comes in that asks for the allQuestions query, that's fine as we find a permission that allows it (the first).

    另一方面，如果经过身份验证的请求针对没有 MODERATOR 角色并包含 deleteQuestion 突变的用户，则没有权限找到这些参数.所以请求被拒绝.

    If on the other hand an authenticated requests comes in for a user that doesn't have the MODERATOR role and includes the deleteQuestion mutation, there is no permission to be found for these parameters. So the request is rejected.

    虽然基于角色的权限已经代表了一个可靠的权限系统，但如果我们想要根据请求者和被请求节点之间的关系来授予权限，它们根本不适合.在我们的示例中，添加允许任何用户删除他们自己的问题/答案的简单规则将是一项艰巨的工作.

    While role-based permissions represent a solid permission system already, they are not suited at all if we want to make granting permission dependant on things like the relation between the requester and the requested node. In our example, it would be quite the work to add the simple rule that any user is allowed to delete their own questions/answers.

    在Graphcool，我们提出了一种强大而相当简单的方法，我们称之为图形权限强> 来解决这个问题.让我们在检查权限时使用以下附加参数:

    At Graphcool, we have come up with a powerful yet rather simple approach that we call graph permissions to tackle this issue. Let's make the following additional parameters available when checking permissions:

    • 哪个节点将被访问或修改?

    由节点id决定

    然后，我们可以使用针对特殊权限架构的 GraphQL 查询来表达权限，以在节点级别授予或拒绝权限.仅当权限查询包含至少一个非 null 的叶节点时，才会授予对给定节点的访问权限.

    Then we can express permissions using a GraphQL query against a special permission schema to grant or reject permissions on a node level. Access to a given node is only given, if the permission query contains at least one leaf-node that is not null.

    在我们的例子中，我们可以指定这个权限查询:

    In our case, we could specify this permission query:

    query {
      allAnswers(filter:{
          authorId: $userId,
          id: $nodeId
      }) {
        id
      }
    }
    

    对于由 GraphQL 变量 $userId 和 $nodeId 指定的给定节点和用户，我们使用查询参数 filter 返回一个如果节点不是由当前用户创建的，则为空列表，否则为非空.

    For a given node and user specified by GraphQL variables $userId and $nodeId, we use a query argument filter to either return an empty list if the node wasn't created by the current user, or something non-null otherwise.

    这篇关于GraphQL 服务器中的授权的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！