这是一个创建于 583 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近看一个 node 项目。
accessToken 通过 jsonwebtoken.sign(JwtPayload, private_cert) 获得，
接收到 FE 请求的时候，通过 jsonwebtoken.verify(accesstoken, public_cert) 来获得 JwtPayload 验证.
这样其实是不是说，FE/Client 其实不对服务端返回的数据做解密啥的,
而服务端对非 public 的接口请求通过 jsonwebtoken.verify 做验证请求合法性
accessToken 通过 jsonwebtoken.sign(JwtPayload, private_cert) 获得，
接收到 FE 请求的时候，通过 jsonwebtoken.verify(accesstoken, public_cert) 来获得 JwtPayload 验证.
这样其实是不是说，FE/Client 其实不对服务端返回的数据做解密啥的,
而服务端对非 public 的接口请求通过 jsonwebtoken.verify 做验证请求合法性
7 条回复 • 2023-04-20 13:33:50 +08:00
 |
1
clickhouse 2023-04-20 12:35:37 +08:00
JWT 里面的数据你可以认为是明文（就是 Base64 ），JWT 验签是为了防篡改。
|
 |
2
IndieCreator OP @clickhouse 嗯嗯，其实这个其实只限制 FE -> Server 数据不被篡改, 不能保证 Server->FE 不被篡改吧，当然 FE 如果有 public cert 的话可以验证是否被篡改
|
 |
3
CEBBCAT 2023-04-20 12:51:47 +08:00
在客户端看来 JWT 只是一个 token ，解码不是必须的。
而服务端解码是为了获取自己当时编码在 JWT 里面的信息，验签则是为了确认收到的这个 JWT 是自己签发的，未经篡改。 对于评论区提出的问题，也就是中间人，需要通过 HTTPS 来解决 |
|
4
IndieCreator OP @CEBBCAT 哦哦，明白了，谢谢，其实这个如果这个 token 自动回传机制的话，对于 FE 来说这个其实是透明的
|
|
5
CEBBCAT 2023-04-20 13:02:58 +08:00
是的，是透明的。不过我刚才想到，JWT 的签名算法有对称的，也有非对称的。如果 FE （你指的是前端对吧？）也想验证 JWT 合法性的话，可以用签发私钥对应的公钥来验证，不过公钥来源又成了一个问题，而且能有多大意义也有待商榷
|
 |
6
houshuu 2023-04-20 13:13:44 +08:00
之前做后端 jwt 验证的时候是指定公司内部的一个 api 定期获取所有 kid 的公钥，然后读 jwt 内的 kid 去找公钥验证。
|
|
7
IndieCreator OP |
Select Language