ayo*_*age 13 api roles token jwt
我正在考虑使用JWT.在jwt.io示例中,我在有效负载数据中看到以下信息:
"admin": true
管理员可以被视为一个角色,因此我的问题.将令牌有效负载中的角色设置为习惯/良好实践吗？鉴于可以动态修改角色,我很有疑问.
B12*_*ter 17
JWT官方站点明确提到“授权”（与“身份验证”相反）作为JWT的用例：
什么时候应该使用JSON Web令牌？ 授权：这是使用JWT的最常见方案。一旦用户登录，每个后续请求将包括JWT，从而允许用户访问该令牌允许的路由，服务和资源。单一登录是当今广泛使用JWT的一项功能，因为它的开销很小并且可以在不同的域中轻松使用。
话虽如此，从安全性的角度来看，您是否应该三思而后行，是否真的要在令牌中包含角色或权限。
（下面的文本可以理解为对“短暂”接受的答案的更“深入”的跟进）
创建并签名令牌后，您将授予权限，直到令牌过期。但是，如果您不小心授予了管理员权限怎么办？在令牌到期之前，现在有人在您的站点上使用错误分配的权限进行操作。
有人可能会认为令牌是短命的，但是考虑到一个人在短时间内可能造成的伤害，这并不是一个有力的论据。其他一些人则主张为令牌维护一个单独的黑名单数据库表，这解决了令牌失效的问题，但是向后端添加了某种会话状态跟踪，因为您现在需要跟踪在那里存在的所有当前会话。 –因此，每次请求到达时，您都必须对黑名单进行数据库调用，以确保尚未将其列入黑名单。可能有人会争辩说，这违背了“首先将角色放入JWT以避免额外的数据库调用”的目的，因为您只是将额外的“角色数据库调用”换成了额外的“黑名单数据库调用” 。
因此，除了向令牌添加授权声明之外，您还可以将有关用户角色和权限的信息保留在您可以随时完全控制的身份验证服务器的数据库中（例如，撤消对用户的特定权限）。如果请求到达，则从身份验证服务器（或存储权限的任何位置）获取当前角色。
顺便说一句，如果您查看IANA注册的公共声明列表，您会发现这些声明围绕认证而发展，并且与用户被允许做的事情（授权）无关。
总而言之，您可以...
如果（a）便利性对您很重要，并且（b）您想要避免额外的数据库调用来获取权限，并且（c）不在乎某个人分配了他不应分配的权利的小时间窗口，则可以向JWT添加角色具有和（d），您不必担心由于添加权限而导致的JWT有效负载的（轻微）增加。
如果（a）您想阻止某人有权分配他不应该拥有的权利的任何时间窗口，并且（b）接受这样做是以向黑名单提出请求为代价的，则将角色添加到您的JWT并使用黑名单对于每个传入请求，（c）您都不关心JWT的有效负载的（轻微）增加是由于添加权限而导致的。
如果（a）您想阻止某人有权分配他不应该拥有的权利的任何时间窗口，或者（b）避免黑名单的开销，或者（c）避免增加任何时间，请不要在您的JWT中添加角色并按需获取它们 JWT有效负载的大小会略有增加，并且（d）如果您接受这样做的代价是有时/总是查询传入请求中的角色。
cas*_*lin 10
如果对您的客户有用,那么您就无法阻止您在令牌中创建额外信息的声明.
但是我只依靠JWT进行身份验证(调用者是谁).如果需要执行授权(调用者可以执行的操作),请从持久存储中查找调用方角色/权限以获取最新值.
如前所述这里，ASP.NET核心会自动检测到任何roles在JWT中提到：
{
"iss": "http://www.jerriepelser.com",
"aud": "blog-readers",
"sub": "123456",
"exp": 1499863217,
"roles": ["Admin", "SuperUser"]
}
并将它们“映射”到ASP.NET角色，这些角色通常用于保护应用程序的某些部分。
[Authorize(Roles = "Admin")]
public class SettingsController : Controller
发出（和签名）JWT的服务器通常称为授权服务器，而不仅仅是身份验证服务器，因此，在JWT中包括角色信息（或作用域）是有意义的，即使它们没有注册声明。