关于 JWT 的问题

[IndieCreator]

最近看一个 node 项目。
accessToken 通过 jsonwebtoken.sign(JwtPayload, private_cert) 获得，
接收到 FE 请求的时候，通过 jsonwebtoken.verify(accesstoken, public_cert) 来获得 JwtPayload 验证.

这样其实是不是说，FE/Client 其实不对服务端返回的数据做解密啥的,
而服务端对非 public 的接口请求通过 jsonwebtoken.verify 做验证请求合法性

[clickhouse]

JWT 里面的数据你可以认为是明文（就是 Base64 ），JWT 验签是为了防篡改。

[IndieCreator]

@clickhouse 嗯嗯，其实这个其实只限制 FE -> Server 数据不被篡改, 不能保证 Server->FE 不被篡改吧，当然 FE 如果有 public cert 的话可以验证是否被篡改

[CEBBCAT]

在客户端看来 JWT 只是一个 token ，解码不是必须的。
而服务端解码是为了获取自己当时编码在 JWT 里面的信息，验签则是为了确认收到的这个 JWT 是自己签发的，未经篡改。

对于评论区提出的问题，也就是中间人，需要通过 HTTPS 来解决

[IndieCreator]

@CEBBCAT 哦哦，明白了，谢谢，其实这个如果这个 token 自动回传机制的话，对于 FE 来说这个其实是透明的

[CEBBCAT]

是的，是透明的。不过我刚才想到，JWT 的签名算法有对称的，也有非对称的。如果 FE （你指的是前端对吧？）也想验证 JWT 合法性的话，可以用签发私钥对应的公钥来验证，不过公钥来源又成了一个问题，而且能有多大意义也有待商榷

[houshuu]

之前做后端 jwt 验证的时候是指定公司内部的一个 api 定期获取所有 kid 的公钥，然后读 jwt 内的 kid 去找公钥验证。

[IndieCreator]

@CEBBCAT 嗯嗯。 我指的是非对称加密
@houshuu 原来这样啊，这把我公钥提供方式的疑问的解决了.