服务器在身份验证期间为客户端提供JWT。JWT包含的信息后来由服务器使用。例如，JWT可能包含permissions数组，其中包含授予特定用户的所有权限的列表。
如果客户解析JWT并使用其中包含的权限信息，它是否被视为不良习惯？客户端对服务器进行额外调用（例如GET /permissions）是否更好？
这将在很大程度上取决于许多小细节；我会尽量不要忘记任何事情，但是从理论上讲，这样做应该可以，如果满足某些条件，我不会认为这是不良的练习。
oauth2指出，访问令牌应该对客户不透明，但是JWT只是一种令牌格式（Learn JSON Web代币），在其他情况下，它的用法并不意味着与OAuth2相同的规则。
。还要注意，从附加请求中获取信息具有相同的最终结果，而另一个呼叫的额外开销。鉴于您可以重复通话，如果权限非常波动，将会有一个轻微的好处。
但是，重要的部分更专注于您的含义，客户将如何使用该信息，因此我将对此进行详细说明。
假设：
- 您提到的客户端可以用作基于浏览器的应用程序（SPA），本机应用程序，也可以是某些用作客户端的服务器端组件。
- 服务器和客户端都由相同的实体控制。
- 可以将客户端和服务器组件视为一个单个应用程序，也就是说，对于最终用户而言，有客户和服务器组件没有区别。他们整体使用它们。
解释
在这种情况下，服务器发出的令牌只是客户以后访问受保护资源而无需再次明确的用户身份验证的方式；这是维护两个组件之间会话的机制。
给定相同的实体控制客户端和服务器，将接收给令牌视为白盒而不是BlackBox 是可以接受的。然后，客户可以解释令牌中的信息，并利用它为最终用户提供更好的体验。但是，这意味着服务器将需要继续验证令牌，并且相应的权限;客户对数据的任何解释纯粹是为了提供可选功能。
此外，对于被部署到敌对环境的客户，例如，对于水疗应用程序而言，通过查看数据做出的决定只能导致纯粹的美学决策，因为用户可以伪造权限数据。例如，您可以使用它来有条件隐藏/禁用某些用户界面，以便用户不必单击它即可发现不允许这样做。
一个好的类比是基于JavaScript的Web表单中的输入验证；您应该这样做以获得更好的用户体验，但是服务器需要再次进行操作，因为用户可以绕过JavaScript验证。