http - 将用户的权限存储在 JWT 声明中或在每次请求时在服务器上检查它是否更有效？

Question

JWT是确保发送给用户和返回给用户的数据未被篡改的好方法，但这会带来一些艰难的选择。目前，我在将授权数据存储在 JWT 声明中和仅接触数据库一次以进行授权之间做出选择，或者仅存储用户 ID 并使用数据库检查对服务器的每个请求的授权级别。

之所以做出如此艰难的选择，是因为该应用程序使用多个授权级别，这使得 base64 编码的 url 非常长且体积庞大(请参阅下面可以预期存储为授权级别的内容)。

另一方面，要获得授权，需要在数据库中进行两次查找。

所以我的问题如下； 通过将权限发送到服务器而在每个请求上产生的额外开销是否值得避免在每个请求时查找权限的麻烦？

作为旁注；在权限更改的情况下，在数据库中查找方法的好处是不需要用户再次登录 (see post)。

"perms": {
    "roles": [
        {
            "name": "Admin",
            "id": 1,
            "assigned": true
        },
        {
            "name": "Webmaster",
            "id": 8,
            "assigned": true
        }
    ],
    "actions": [
        {
            "id": 1,
            "name": "cms-edit",
            "parameters": null,
            "parameterized": null
        },
        {
            "id": 9,
            "name": "admin-syslog",
            "parameters": null,
            "parameterized": null
        },
        {
            "id": 10,
            "name": "admin-debug",
            "parameters": null,
            "parameterized": null
        },
        {
            "id": 12,
            "name": "member-list-extended",
            "parameters": null,
            "parameterized": null
        },
        {
            "id": 2,
            "name": "cms-list",
            "parameters": null,
            "parameterized": null
        },
        {
            "id": 3,
            "name": "cms-add",
            "parameters": null,
            "parameterized": null
        },
        {
            "id": 5,
            "name": "member-list",
            "parameters": null,
            "parameterized": null
        },
        {
            "id": 7,
            "name": "member-view",
            "parameters": null,
            "parameterized": null
        },
        {
            "id": 8,
            "name": "member-edit",
            "parameters": null,
            "parameterized": null
        }
    ]

Answer 1

您的第一个问题:

Is the extra overhead on each request by sending the permissions to the server worth avoiding the hassle of looking up the permissions upon each request?

回答:

让我们看一下 jwt.io 提供的关于何时使用 JWT 的描述:

Authorization: This is the most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. Single Sign On is a feature that widely uses JWT nowadays, because of its small overhead and its ability to be easily used across different domains.

这意味着您需要在用户登录后在服务器端生成 token 。

它包含:

• 用户(作为 ID 或名称)
• 客户的角色(用户、管理员、 guest 等...)

一旦客户端请求或向服务器发送数据，服务器首先检查给定的 token 是否有效且已知，然后它会检查角色是否满足访问特定资源的条件。

所有角色/访问数据都可以在系统启动时读取一次并保存在内存中。此外，客户端具有的角色仅在客户端登录时从数据库中读取一次。这样您就没有后续的数据库访问，因此性能得到了很大的提高。

另一方面，如果客户端请求数据或想要执行操作，您需要一种身份验证机制来评估传递的 token 是否具有执行此操作所需的角色。

这样我们解决了数据库的麻烦，而且我们消除了向客户端暴露过多信息的危险(即使客户端不能篡改数据，它也可以读取数据!)

请注意:https://jwt.io/introduction

Do note that with signed tokens, all the information contained within the token is exposed to users or other parties, even though they are unable to change it. This means you should not put secret information within the token.

参见 A3(敏感数据暴露):https://www.owasp.org/index.php/Top_10-2017_Top_10

最后:如果客户端闲置时间过长或故意注销，请务必使 token 失效。

后续问题:

The case of permission changes the look-up-in-the-database approach has the benefit of not requiring the user to log in again

回答:

根据您服务器的基础设施，您可以编写一个刷新机制(如果角色更新，服务器生成一个新 token 并将其与生成的答案一起发送给客户端，使旧的无效，客户端仅使用最近的 token 并覆盖旧的)或在服务器端添加一些状态，如客户端 session :

消除 token 处的角色/权限。您最好为客户端生成 session 并在服务器端提供 session 角色/权限。客户端获取它可以用来进行身份验证的 session token (通常是一个 ID)。一旦权限/角色发生变化，我们必须做两件事:

1. 更新数据库
2. 更新 session 的角色/权限

同样，每个后续请求都将在内存中进行角色/权限检查，不需要数据库通信，而客户端只有一个小 session token (或您的 JWT)。因此，角色/权限更改对客户端是透明的(不需要重新登录)，我们消除了 JWT 刷新要求。