|
|
1
378
JWTs可以是签名的、加密的,也可以两者兼有。如果令牌已签名,但未加密,则每个人都可以读取其内容,但当您不知道私钥时,则无法更改它。否则,接收者将注意到签名不再匹配。 回答你的评论:我不确定我是否理解你的评论的正确方式。只是确定一下:你知道并理解数字签名吗?我只简单地解释一个变体(HMAC,它是对称的,但是还有很多其他变体)。
假设爱丽丝想给鲍勃寄一张JWT。他们都知道一些共同的秘密。马洛里不知道这个秘密,但想干涉和改变JWT。为了防止这种情况,爱丽丝计算了一下
当接收到消息时,Bob还可以计算
假设,我给另一个人发信息
|
|
|
2
131
你可以去
简而言之,JWT并不关心加密。它关心验证。也就是说,它总能得到“操纵此令牌内容”的答案?这意味着用户对JWT令牌的操作是徒劳的,因为服务器将知道并忽略该令牌。当向客户机颁发令牌时,服务器根据负载添加签名。稍后它将验证有效负载和匹配的签名。 合乎逻辑的问题是,什么是不关注加密内容的动机?
这和饼干本身的工作原理没有太大区别。Cookies通常包含未加密的有效载荷。如果你使用的是HTTPS,那么一切都很好。如果你不这样做,那么最好自己加密敏感的cookie。不这样做将意味着中间人攻击是可能的——代理服务器或ISP读取cookies,然后在以后假装成您时重放它们。出于类似的原因,JWT应该总是在像HTTPS这样的安全层上进行交换。 |
|
|
3
16
json web令牌(JWT)中的内容本身并不安全,但有一个用于验证令牌真实性的内置功能。JWT是由句点分隔的三个散列。三是签名。在公钥/私钥系统中,颁发者使用只能由其相应的公钥验证的私钥签署令牌签名。 理解发行人和验证者之间的区别是很重要的。令牌的接收者负责验证它。 在web应用程序中安全地使用JWT有两个关键步骤:1)通过加密的通道发送它们,2)在接收到签名后立即验证它。公钥密码的非对称性使得JWT签名验证成为可能。公钥验证JWT是否由其匹配的私钥签名。没有其他密钥组合可以执行此验证,从而阻止模拟尝试。按照这两个步骤,我们可以用数学上的确定性来保证JWT的真实性。 |
|
|
4
1
只有JWT的私有密钥(位于服务器上)才能解密加密的JWT。那些知道私有密钥的人将能够解密加密的JWT。 将私钥隐藏在服务器的安全位置,不要告诉任何人私钥。 |
|
|
5
0
对于像我这样负担不起昂贵的数据库查询的人来说,保留敏感数据(用户priveledges等)的一个选择是,在生成JWT时,您可以加密这些数据并将其附加到JWT令牌。(将加密密钥保留在后端) 当您想读取敏感信息时,可以将JWT令牌发送到后端并对其进行解密,然后将信息取回。这样,您就不必通过JWT令牌在前端执行DB查找或将敏感信息裸露出来 |
|
6
-1
我建议在研究JWE时使用特殊算法,这在智威汤逊解密 参考链接: https://www.npmjs.com/package/node-webtokens
这个答案可能太晚了,或者你可能已经找到了路,但是,我仍然觉得这对你和其他人都有帮助。 我创建了一个简单的示例: https://github.com/hansiemithun/jwe-example |
|
|
Mist · Web API和属性路由 8 年前 |
|
|
brazuka · Angular中令牌验证的最佳方式 8 年前 |
|
Don Diego · 解码时的Javascript标记、JWT和数字 8 年前 |
|
Sergio · 如何从Automapper配置文件中获取用户标识 8 年前 |
|
|
Yuseferi · 在浏览器上重新生成(刷新)令牌 8 年前 |
|
|
buff · 在缓存中存储全局令牌 8 年前 |