JWT ( JSON Web Token)

“Token可以放在浏览器的localStorage、请求headers、甚至有时放在请求url里。那么如果黑客截获了我的 Token，是不是就能伪造我的身份？”

答案确实如此，如果 Token 被截获，黑客确实可以伪造身份。 但是JWT 的设计初衷和安全机制并非在于“防止被截获”，而在于**“防篡改”和“自包含”**。

自包含

自包含很好理解，就是服务端通过token就可以从payload中获取必要的信息（用户名、用户id、角色等），不需要额外查询就能知道token这个人是谁

JWT 如何保证数据不被篡改？

JWT 的结构分为三部分：Header.Payload.Signature。

• Header & Payload：这两部分其实就是简单的 Base64 编码，没有加密，解码一下就可以看到里面完整的信息。所以不要在这里面去存储明文的密码等敏感信息。而header和payload的区别也很简单，一个存储一些元数据（比如签名方法）。而payload存储一些必要的业务信息。

• Signature：这是它是由服务端拿着“私钥（Secret）”对前两部分进行哈希计算生成的。存储的就是最后的计算结果

  所以假设黑客修改了 Payload 里的 role，尝试把自己变成管理员。当服务端收到 Token 时，会用同样的私钥再次计算签名。由于 Payload 变了，计算出的签名肯定和 Token 自带的 Signature 不一致，服务端直接判定非法。

  关于signature签名和验证的详细细节，可自行前往学习：https://kucw.io/blog/jwt-signature/

2. JWT 存储在哪才安全？

再结合我们前面聊到的前端安全两大威胁XSS 和 CSRF，JWT 应该存在哪？或者说应该怎么正确姿势使用JWT呢

存储位置	防 CSRF	防 XSS
Cookie	⚠️配合现代浏览器的一些方案（如SameSite，可防御绝大部分CSRF	✅（开启HttpOnly）
localStorage	✅	❌ 只要有xss攻击，攻击者就相当于拥有登陆状态
存内存 + Access Token + Refresh Token	✅	⚠️攻击者只能拿到内存中的Access Token，只能在短短10几分钟内的时间发起攻击

3、双token鉴权机制

结论：

方案三的双token机制是目前最为完善的解决方案；cookie + 一些简单的方案也可以防止绝大部分的攻击；因此根据自身工程情况进行选择即可。