JWS（JSON Web Signature，JSON 网络签名）和 JWE（JSON Web Encryption，JSON 网络加密）是 JOSE（JSON Object Signing and Encryption）标准族里的一对搭档：JWS 解决“这段话是谁说的、有没有被人改过”，JWE 解决“这段话会不会被旁人看到”——它们回答的是两个不同的问题。
先看 JWS：明信片上加封印
JWS 的产物是大家都见过的三段式字符串 header.payload.signature。做法是：把头部和载荷各做一次 base64url 编码，用点拼起来，然后对这个整体计算签名——对称场景用 HMAC 共享密钥，非对称场景用 RSA/ECDSA 私钥签、公钥验。验证方重算一遍签名比对，对得上就说明两件事：内容一个字节都没被改，且持有签名密钥的那一方签的。
关键在于：base64url 是编码，不是加密。任何人拿到 payload 段，随便一个解码工具就能读出明文。签名像在明信片上盖了个火漆印——路上谁都能读内容，但改一个字印就对不上。
再看 JWE：上锁的保险箱
JWE 是五段式结构，依次是头部、加密后的内容密钥、初始化向量、密文、认证标签。载荷真正被加密算法保护，只有持有解密密钥的一方能还原。旁人看到的是一串乱码。
比方说：JWE 是把信放进保险箱。内容绝对保密，但保险箱谁都能往里面扔东西——收到一个保险箱，并不能证明是谁寄的。
两者的分工
| JWS | JWE | |
|---|---|---|
| 核心目标 | 完整性 + 来源认证 | 机密性 |
| 内容是否可读 | 可读（仅编码） | 不可读 |
| 能否证明发送方 | 能 | 一般不能（需额外签名） |
| 典型形态 | a.b.c 三段 | 五段 |
| 常见用途 | ID AI 词典：Token">Token、webhook 验签、API 请求防篡改 | 传递敏感字段、端到端加密载荷 |
最常见的事故：把签名当加密
实践中最典型的翻车，是把用户手机号、身份证号、内部权限标记塞进一个 JWT（JSON Web Token）发给前端，以为“token 是加密的，用户看不到”。而绝大多数 JWT 默认就是 JWS 形态，浏览器开发者工具里一解码，明文全在。这不是算法漏洞，是概念错位。
反过来的错误同样存在：有人收到一段自己能解开的 JWE，就默认对方身份可信。加密只保证“别人看不到”，不保证“是谁写的”。既要保密又要防伪，做法是嵌套——先签名再加密，或先加密再签名，两层各管一件事。
对从业者的实际意义
- 设计 AI 应用的接口时，第三方回调（webhook）用 HMAC 签名校验来源，别用加密代替。
- Agent 之间传递凭证或用户数据，先问自己：怕被看，还是怕被改？怕被看用 JWE，怕被改用 JWS。
- 审查 token 设计时，把“这段 payload 出现在浏览器里会不会出事”当成必答项。
- 一句话记住：签名不藏内容，加密不证身份。具体算法与库的支持情况，以 IETF 的 RFC 7515/7516/7519 和各库官方文档为准。