我正在考虑使用JWT。在jwt.io example我看到有效载荷数据中的以下信息：
"admin": true
管理员可以被视为一个角色，因此我的问题。将令牌有效负载中的角色设置为习惯/良好实践吗？鉴于角色可以动态修改，我很有疑问。
答案 0 :(得分：6)
如果对您的客户有用，则无法阻止您创建声明中存储额外信息的声明。
但是我只依赖JWT进行身份验证（调用者是谁）。如果您需要执行授权（调用者可以执行的操作），请从持久存储中查找调用方角色/权限以获取最新值。
答案 1 :(得分：4)
JWT官方站点明确提到“授权”（与“身份验证”相反）作为JWT的用例：
何时应使用JSON Web令牌？ 授权：这是使用JWT的最常见方案。一旦用户登录，每个后续请求将包括JWT，从而允许用户访问该令牌允许的路由，服务和资源。单一登录是当今的一种广泛使用JWT的功能，因为它的开销很小并且可以轻松地在不同域中使用。
话虽如此，从安全性的角度来看，您应该三思而后行，是否真的要在令牌中包含角色或权限。
（以下文本可以理解为对“短暂”接受的答案的更“深入”的跟进）
创建并签署令牌后，您将授予权限，直到令牌过期。但是，如果您不小心授予了管理员权限怎么办？在令牌失效之前，现在有人在您的网站上使用错误分配的权限进行操作。
有些人可能会认为令牌是短命的，但是考虑到一个人在短时间内可能造成的伤害，这并不是一个强有力的论据。其他一些人则主张为令牌维护一个单独的黑名单数据库表，这解决了令牌失效的问题，但是向后端添加了某种会话状态跟踪，因为您现在需要跟踪在那里存在的所有当前会话。 –也使得难以实现负载平衡...
因此，您无需在令牌上添加授权声明，而是可以将有关用户角色和权限的信息保留在您可以随时完全控制的（本地）数据库中（例如，撤消对用户的特定权限）。 –使用此解决方案可获得额外的奖励积分：在您为他/她的帐户分配了不同的角色后，用户无需再次登录！
顺便说一句，如果您查看public claims registered by the IANA的列表，您会发现这些声明围绕认证而发展，并且与用户被允许做的事情（授权）无关。
答案 2 :(得分：3)
如here所述，ASP.NET Core将自动检测JWT中提到的任何roles：
{
"iss": "http://www.jerriepelser.com",
"aud": "blog-readers",
"sub": "123456",
"exp": 1499863217,
"roles": ["Admin", "SuperUser"]
}
并将它们“映射”到ASP.NET Roles，通常用于保护应用程序的某些部分。
[Authorize(Roles = "Admin")]
public class SettingsController : Controller
提供（并签名）JWT的服务器通常称为authorization server，而不仅仅是 authentication 服务器，因此包含角色信息（或作用域）是有意义的在JWT中，即使它们不是registered claims。