🔐 JWT 不是会话，签名不等于安全
很多人第一次接触 JWT（JSON Web Token）时，会把它理解成“更高级的登录态”。这一步就容易踩坑。JWT 的核心作用不是“让服务器记住你”，而是“让服务器相信这段令牌里的内容没被篡改”。它通常由三段组成：header、payload、signature。前两段只是 Base64URL 编码，谁都能解开看；真正提供保护的是最后的签名。问题也正出在这里：很多系统把“签名有效”误当成“内容可信到可以随便塞敏感信息”。
为什么会出事？因为开发者常把用户角色、权限范围、邮箱、内部编号，甚至临时授权状态直接放进 payload，然后让业务代码到处读取。这样一来，只要密钥泄露、算法校验写错、密钥管理混乱，攻击者就能伪造一个“签名正确”的高权限令牌。更糟的是，JWT 默认是自包含的，它不像传统 session 那样天然依赖服务端状态，所以一旦签发出去，在过期前往往很难立刻失效。现实里常见的事故不是“JWT 被破解”，而是“JWT 被滥用”：过期时间设太长、刷新机制混乱、服务端不校验 audience/issuer、把注销和权限变更当成了前端问题。
真正实用的防法很朴素。第一，JWT 里不要放不该长期暴露的敏感数据，payload 不是保险箱。第二，永远固定允许的算法，不要让 token 自己决定你怎么验它。第三，严格校验 iss、aud、exp、nbf，这些字段不是摆设。第四，密钥要轮换，签名密钥和别的业务密钥分开。第五，如果你的业务需要“随时踢下线”或“权限变更立刻生效”，那就别神化无状态，老老实实加服务端状态表、黑名单或短生命周期 access token + refresh token 机制。安全不是追求酷，而是别把撤销控制权送出去。
🧪 场景分析题：某后台系统把
💡 核心记忆：JWT 只能证明“这段数据是谁签的、有没有被改”，不能天然解决“权限该不该现在还有效”。
#Security
很多人第一次接触 JWT（JSON Web Token）时，会把它理解成“更高级的登录态”。这一步就容易踩坑。JWT 的核心作用不是“让服务器记住你”，而是“让服务器相信这段令牌里的内容没被篡改”。它通常由三段组成：header、payload、signature。前两段只是 Base64URL 编码，谁都能解开看；真正提供保护的是最后的签名。问题也正出在这里：很多系统把“签名有效”误当成“内容可信到可以随便塞敏感信息”。
为什么会出事？因为开发者常把用户角色、权限范围、邮箱、内部编号，甚至临时授权状态直接放进 payload，然后让业务代码到处读取。这样一来，只要密钥泄露、算法校验写错、密钥管理混乱，攻击者就能伪造一个“签名正确”的高权限令牌。更糟的是，JWT 默认是自包含的，它不像传统 session 那样天然依赖服务端状态，所以一旦签发出去，在过期前往往很难立刻失效。现实里常见的事故不是“JWT 被破解”，而是“JWT 被滥用”：过期时间设太长、刷新机制混乱、服务端不校验 audience/issuer、把注销和权限变更当成了前端问题。
真正实用的防法很朴素。第一，JWT 里不要放不该长期暴露的敏感数据，payload 不是保险箱。第二，永远固定允许的算法，不要让 token 自己决定你怎么验它。第三，严格校验 iss、aud、exp、nbf，这些字段不是摆设。第四，密钥要轮换，签名密钥和别的业务密钥分开。第五，如果你的业务需要“随时踢下线”或“权限变更立刻生效”，那就别神化无状态，老老实实加服务端状态表、黑名单或短生命周期 access token + refresh token 机制。安全不是追求酷，而是别把撤销控制权送出去。
🧪 场景分析题：某后台系统把
role: "admin" 写进 JWT payload，token 有效期 30 天。管理员今天被降权，但他手机里旧 token 还没过期，系统每次只验证签名和 exp。此时最大的安全问题是什么？答案：💡 核心记忆：JWT 只能证明“这段数据是谁签的、有没有被改”，不能天然解决“权限该不该现在还有效”。
#Security
