JWT不是为了授权而设计的，只是用作身份验证。

JWT 主要用于验证身份。由于大多数开发人员不会开发自己的身份验证解决方案，因此身份验证提供商的 SDK 可能会为您完成此操作。您最终从 JWT 获得的是身份本身。

这很好，因为 JWT 是可验证的用户配置文件的最佳来源。因此，您可能不需要亲自验证 JWT，但您可以并且应该将其用作用户身份的真实来源。

除此之外，您还可以使用 JWT 来扩展身份验证提供程序的功能。由于 JWT 是可自我验证的，因此您可以将其用于其他服务，而无需您的身份验证服务参与。

例如，这意味着您可以创建一个内部 OAuth 服务器，让开发人员以更安全可靠的方式使用内部数据。您还可以在共享 API 身份验证或机器对机器身份验证时使用 JWT，因为 JWT 是可验证的。

底线 - JWT 应该用于验证，并作为用户身份和用户资料的真实来源。

JWT 不是什么
用户登录并完成身份验证过程后，我们将进入授权阶段 - 决定用户在我们的应用程序中可以做什么或不能做什么。在此步骤中，我们唯一可验证的是基于 JWT 的用户身份。

JWT 的主要组成部分是其有效负载，其中包含我们可以识别的用户 ID。由于授权与身份验证紧密相关，因此用户不断在此有效负载中存储越来越多的数据。

为了使事情变得简单且不付出太多努力，许多开发人员决定检索 JWT 中的属性并将其与应用程序中的命令式代码配对。这通常会导致出现类似“如果 JWT 角色等于某项，则允许/拒绝某项”的语句。有时，当他们想要创建更动态的东西时，他们会添加一个外部函数来根据 JWT 获取角色。

这是因为许多开发人员将 JWT 的可验证性质视为适合验证权限的东西。

正如我们前面提到的，大多数开发人员在需要处理用户授权时首次接触 JWT。大多数开发人员并不真正了解验证过程，最终由身份验证服务为您提供 JWT。

此时，由于 JWT 可以承载一些定义应用程序中权限的基本范围和声明，许多开发人员倾向于认为，“现在用户已经通过验证，我可以使用此令牌来定义用户应该拥有什么访问权限”。

虽然角色和声明在我们的应用程序权限中扮演着重要的角色，但它们不足以完全定义它们。将 JWT 视为授权组件的这种做法存在两个问题：

1. 虽然 JWT 是过去几年软件开发领域最伟大的发展之一，但它们并不用于授权。
2. 使用 JWT 作为管理应用程序内用户访问的唯一方法可能会对应用程序的安全性造成灾难性的后果。

JWT 是静态的
从授权角度来看，我们可以立即看到这种方法过于静态。让我们以基于角色的访问控制 (RBAC) 为例。在 RBAC 中，我们扮演用户的角色并确定他们是否可以执行特定操作或动作。RBAC 并不止于角色 - 即使像 RBAC 这样简单的授权模型也包含更多组件，例如用户尝试执行的操作以及他们正在执行该操作的资源。

JWT 仅包含这三个组件的第一部分——用户及其可能分配的角色。如果将用户角色作为 JWT 的一部分传递，则无法创建动态角色，从而使我们的授权层完全静态。这意味着在令牌过期之前，过期的权限将一直有效。

例如，如果我有一个管理员用户，我想将其降级为标准用户，除非撤销 JWT，否则我无法这样做。由于 JWT 原则上是可验证的，因此在令牌过期之前无法撤销它。

通常，现在的 JWT 的生存期非常短，因此对于访问令牌，TTL（生存时间）可能约为 60 秒，并且 SDK 会为您刷新它们。因此，我们不能仅仅依赖 JWT 上的角色。

JWT 不够细粒度
由于 JWT 仅包含有关个人用户的信息，因此您可以（并且应该）在其中存储的数据量有非常严格的限制。对于基于属性的访问控制 (ABAC)和基于关系的访问控制 (ReBAC)等模型，使用 JWT 直接创建授权查询变得不可能。

JWT 有大小限制。这意味着，如果我们想授予用户访问 1000 个文件的权限，就必须创建一个 20,057 个字符的 JWT — — 这还只是考虑到一个简单的文件名。如果使用完整路径名，那么长度会更长。

设计授权层的第一步是确定需要管理访问权限的资源。每种类型的资源及其在应用程序整体结构中的位置可能要求您使用不同类型的授权模型（RBAC、ABAC、ReBAC 或它们的组合）。使用 JWT 可能是一种快速的临时解决方案，但它远非可持续。

重要的是，你 要熟悉现有的策略模型、它们的优缺点，并尝试评估哪些模型最适合你的应用

JWT 在授权中应该扮演什么角色？
JWT 并非用于授权，而是用于验证、交换令牌和基于令牌的身份验证。如果我们按照 JWT 的本意使用它们，即作为用户身份的真实来源，那么我们就可以利用它们向外部授权服务查询用户可以做什么或不能做什么。但是，这种使用不应将任何授权逻辑作为 JWT 本身的一部分。

相关：https://www.jdon.com/74012.html