深入解析422无效token：从原理到实战解决方案

1次阅读

共计 2173 个字符，预计需要花费 6 分钟才能阅读完成。

HTTP 422 状态码（Unprocessable Entity）表示服务器理解请求实体的内容类型，且语法正确，但无法处理包含的指令。在 API 开发中，无效 token 导致的 422 错误尤为常见，尤其是在基于 token 的身份验证系统中。

无效 token 通常出现在以下场景：

已过期但仍在使用的访问令牌
被撤销但客户端未感知的令牌
格式正确但签名无效的 JWT
跨系统迁移时遗留的旧版令牌

现代 Web 应用常用的 token 验证流程包含三个关键环节：

令牌签发：认证服务器通过特定算法生成包含声明的令牌
令牌传输：客户端在请求头（通常为 Authorization）携带令牌
令牌验证：资源服务器验证令牌有效性和权限范围

时间因素：超过 exp 声明指定的有效期
空间因素：签发者与验证者使用的密钥不一致
状态因素：令牌已被加入黑名单
格式因素：缺失必要声明或算法不匹配

优点：

无状态设计减轻服务端存储压力
自包含声明减少数据库查询
支持跨域和微服务架构

缺点：

无法单方面废止令牌
载荷内容可能被解码（非加密时）

优点：

完善的令牌刷新流程
支持细粒度的权限控制
生态工具丰富

缺点：

实现复杂度较高
需要维护令牌状态

对于大多数中大型系统，推荐组合使用：

短期访问令牌采用 JWT（1 小时有效期）
长期刷新令牌采用数据库存储
敏感操作配合二次验证

const jwt = require('jsonwebtoken');
const {TokenExpiredError} = jwt;

// 中间件实现
const verifyToken = (req, res, next) => {const authHeader = req.headers['authorization'];
  const token = authHeader && authHeader.split(' ')[1];

  if (!token) return res.sendStatus(401);

  jwt.verify(token, process.env.ACCESS_TOKEN_SECRET, (err, user) => {if (err) {
      // 区分不同类型的验证失败
      if (err instanceof TokenExpiredError) {return res.status(422).json({ 
          code: 'TOKEN_EXPIRED',
          message: 'Access token was expired'
        });
      }
      return res.sendStatus(403);
    }

    req.user = user;
    next();});
};

app.post('/refresh', (req, res) => {
  const refreshToken = req.body.token;
  if (!refreshToken) return res.sendStatus(401);

  // 实际项目应查询数据库验证 refreshToken 有效性
  if (!validRefreshTokens.includes(refreshToken)) {return res.sendStatus(403);
  }

  jwt.verify(refreshToken, process.env.REFRESH_TOKEN_SECRET, (err, user) => {if (err) return res.sendStatus(403);

    const accessToken = generateAccessToken({username: user.username});
    res.json({accessToken});
  });
});

function generateAccessToken(user) {return jwt.sign(user, process.env.ACCESS_TOKEN_SECRET, { expiresIn: '15m'});
}