（哎，这事儿得从一顿火锅说起）上周帮朋友公司排查bug，他们的系统突然所有用户都登录不上去了。最后发现是JWT签名验证没做，黑客随便改个用户ID就能冒充管理员。今儿咱们就唠唠，怎么像老中医把脉一样，把JWT从里到外看个通透。

??第一关：拆开快递包裹看结构??
你们收快递得先看包装完不完整吧？JWT也是这个理儿。它由三部分组成，用点号隔开，长得像这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

这玩意儿分三段：

1. ??头（Header）??：告诉你用的啥算法，比如HS256
2. ??体（Payload）??：装用户信息的货仓
3. ??签名（Signature）??：防伪标识贴

（举个栗子）就像你买iPhone，包装盒是头，手机是体，封口贴纸是签名。要是封贴被撕过，立马知道被人动过手脚。

??第二关：Base64Url解码是门手艺??
这里有个坑！JWT用的是Base64Url编码，不是普通Base64。区别在哪儿呢？看这个对比表：

（手把手教学）拿头部的这段举例：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

用在线工具解码后得到：

json复制
{
  "alg": "HS256",
  "typ": "JWT"
}

注意啊！千万别用这方法解析用户传过来的token，得用程序自动验证签名。之前有个哥们手动解码后直接信了，结果被人伪造token骗走数据库权限。

??第三关：签名验证是命门??
这里必须上代码了，咱们用Node.js举例：

javascript复制
const jwt = require('jsonwebtoken');

try {
  const decoded = jwt.verify(用户传的token, '你的密钥', {
    algorithms: ['HS256'] // 重点！必须指定算法白名单
  });
  console.log("验货通过:", decoded);
} catch (err) {
  console.log("抓到假货了！", err.message);
}

（血泪教训）见过最离谱的漏洞是不验证算法类型。黑客把header改成{"alg":"none"}，直接绕过了签名验证。所以必须像上面代码那样强制指定允许的算法。

??第四关：过期时间不是摆设??
Payload里这个字段得重点盯防：

json复制
{
  "exp": 1730217600, // 2024-10-30 00:00:00
  "nbf": 1730217000  // 生效时间不能早于这个
}

（真实案例）某电商平台促销活动时，有人把过期时间改成300年后，用脚本疯狂刷优惠券。所以验证时务必检查这两个时间戳：

1. 当前时间是否超过exp
2. 当前时间是否晚于nbf

??第五关：黑名单机制补漏洞??
有人说JWT不能强制注销？那是没找到窍门！两种方案任选：

python复制
# 方案A：内存黑名单（适合小型系统）
blacklist = set()

def verify_token(token):
    if token in blacklist:
        raise Exception("此令牌已作废")
    # ...其他验证逻辑

# 方案B：短期token+刷新机制（推荐）
# 主token有效期15分钟，用refresh token续期

（避坑指南）千万别用方案A处理高并发系统，内存会爆炸。去年双十一某平台用Redis存黑名单，结果QPS太高直接把缓存打崩了。现在主流做法都是让token自然过期，敏感操作要求二次验证。

??小编观点??
搞JWT解析就像炒菜放盐，少了没味，多了齁死人。见过太多项目要么完全不验证签名，要么验证逻辑写得太复杂反而出漏洞。记住三个核心：??强制算法白名单、严格检查时间戳、关键操作加二次验证??。按这个套路来，至少能防住九成的常见攻击。最后说句掏心窝的——安全这事儿，宁可麻烦点，也别等出事了再哭爹喊娘！