使用JWT的角色

use*_*687 29 jwt

我是JWT的新手.我对JWT进行了一些研究,并了解到它被构造为"header.claims.signature".

考虑一个简单的场景如下:

  • 客户获得身份验证
  • 客户可以拥有(一个或多个)admin,member,registered,guest角色
  • 服务器不维护任何会话(并且仅依赖于JWT进行身份验证/授权)

经过身份验证后,服务器会找到客户的类型,我假设customerId和角色将成为JWT中"声明"的一部分.如果我的假设不正确(或违反标准),请告诉我.

JWT的"声明"部分未加密(仅编码).这暴露了一个简单的安全漏洞,其中(服务)消费者可以简单地修改JWT的"声明"部分并重新发送更多角色(客户/消费者未被授权).

如果我的理解/假设不正确,我们如何实现我的目标?

Bri*_*ell 29

使用JWS(header.claims.signature)时,JWT的"声明"部分受签名的完整性保护.因此,如果JWT的"声明"或任何其他部分被没有正确密钥的人修改,则JWT上的签名验证将失败并且令牌应被拒绝.

  • jwt.io上的工具正在修改JSON声明时更新签名.如果您要在其他地方修改JWT并将其粘贴,则工具会报告无效签名.例如,这JWT已签名calculted超过索赔W /"管理":假的,但随后的权利要求/载荷修改为"admin":真实,因此签名是无效的:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.uI_rNanTsZ_wFa1VnICzq2txKeYPArda5QLdVeQYFGI (8认同)

Ham*_*eji 9

claims可以验证JWT 的一部分,但claims在更改用户角色时添加类似角色的另一个问题是,但旧令牌仍包含分配给用户的先前角色.所以要小心.您可以简单地将用户标识符保留在令牌中,并根据您的持久性机制(数据库或其他任何内容)检索与用户关联的任何其他信息.