[不懂就问]JWT 中 header 和 signature 真的有必要存在吗？直接使用 payload 部分对称加密不好吗

一个是签名，一个是加密，两个不是同一个东西。加密完以后客户端还怎么读 payload 和 header 的内容？

> 客户端修改之后回来再解密肯定出错
不正确。事实上如果不带 AEAD 的加密算法，是无法保证原文不被修改的。

> jwt 为什么不加密

Although JWTs can be encrypted to also provide secrecy between parties, we will focus on signed tokens. Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties. When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.

以上说明来自官网介绍 https://jwt.io/introduction

我觉得 JWT 只是一种规范。
会指定算法名称，是因为加密或者签名，它不依赖于攻击者不知道你用的什么算法。

像一楼说的，加密了客户端不就没法读了
客户端要是不用读那给他全文干啥，存在服务端给它个 session id 不就完了，连加密都省了

保持完整性比加密重要。对称加密你要一用户一密钥吗？还是一 session 一密钥呢？服务开销大不大？密钥交换怎么解决？重放攻击能挡得住不？
由于 jwt 是可信端签发的单向数据，仅作签名验证权威性和保证完整性就足够了，没人逼你在 jwt 放用户余额等业务数据。
完整的 jwt 还含有多种 token 来保障业务需求，比如服务端主动过期 session 。业务合适的话 jwt 方案不失为一套快速解决方案。个人还是倾向 saml 。

如果不需要给客户端读，只是原样返回的话，那没必要用 jwt，直接发个 token 就行了，token 里可以密文存储用户身份，别人都不知道怎么解密，只有你自己能看

JWT 可以把 payload 加密，不加密的是为了让客户端也能读取里面的数据。

想想为什么会存在 iss，就明白为什么非对称加密（签名和校验）在某些场景下是必须的了

更主要的原因是没必要，基本功能是身份验证，表示确实是这个人发的，但你加密了 payload 也需要 js 解密，而 js 通常是通过 https 发给客户端的，流量已经被加密了，再加密也是多此一举，如果你的环境连 https 都无法保证秘密和安全了，加密也没有用，攻击者可以改你的 js 或相关的流量；如果你说你走别的渠道分发客户端代码，并使用双向认证，你分发的渠道还是会面临这个问题，当然，这可能可以提高攻击者的成本和难度，但这需要一系列的安全加固，任何一个地方出现问题就白干了（木桶效应）。

@skinny 当然，https 不能信任了，签名也白搭，所以只需要最基本的验证，还有是防止重放这些

@skinny 之前是没想到 payload 是给客户端看的，一直以为是给后端看的...