JavaScript中使用RS256算法验证JWT返回403错误问题咨询

jwt.verify()执行逻辑说明 #

jwt.verify() 绝对不是对比两个输入参数是否相等，RS256是非对称加密算法，该方法的参数定义和执行逻辑如下：

• 第一个入参：必须是完整的JWT字符串（格式为xxxxx.yyyyy.zzzzz的三段式结构）
• 第二个入参：对应算法的验证密钥，RS256场景下是和签发私钥配对的公钥
• 执行步骤：
  1. 解析第一个入参的JWT格式，拆分头部、载荷、签名三个部分，格式不合法直接抛出错误
  2. 校验JWT头部声明的签名算法是否符合预期，不匹配直接抛出错误
  3. 用传入的公钥对JWT前两部分的哈希值做签名校验，确认签名是配对私钥签发，校验不通过直接抛出错误
  4. 校验JWT载荷中的内置声明，比如过期时间exp、生效时间nbf等，不符合规则直接抛出错误

你之前执行的jwt.verify(publicKey, publicKey)是完全错误的测试方式，第一个入参不是合法JWT格式，必然验证失败，不能用来证明密钥有问题。 #

现有代码问题及修复方案 #

存在的问题 #

1. 未校验Authorization请求头的合法性：如果请求没有携带Authorization头、或者头格式不是Bearer 令牌的规范格式，authorization[1]会是undefined，传入verify方法必然报错
2. 验证时未显式指定算法：jwt.verify默认允许多种算法，不仅有安全风险，也可能因为算法不匹配导致验证失败
3. 错误日志缺失：所有错误都统一返回403，无法区分是令牌过期、格式错误、签名无效还是密钥问题，无法定位根因
4. 公钥每次请求都重复读取文件：无意义的IO操作会降低接口性能

修复后的验证代码 #

import createError from 'http-errors'
import fs from 'fs'
// 服务启动时一次性读取公钥即可，无需每次请求读文件
const publicKey = fs.readFileSync('./public.pem', 'utf8')

const authorize = (req, res, next) => {
  const authorization = req.headers.authorization
  // 先校验请求头格式
  if (!authorization || !authorization.startsWith('Bearer ')) {
    return next(createError(401, '缺少合法身份凭证'))
  }
  const token = authorization.split(' ')[1]
  try {
    // 显式指定验证算法和签发时保持一致
    const payload = jwt.verify(token, publicKey, { algorithms: ['RS256'] })
    // 可将解析后的载荷挂载到req对象，供后续路由使用
    req.userPayload = payload
    next()
  } catch (err) {
    // 打印错误详情方便定位，生产环境可调整为日志上报
    console.error('JWT验证失败：', err.name, err.message)
    // 按错误类型返回不同提示，方便前端处理
    if (err.name === 'TokenExpiredError') {
      return next(createError(401, '身份凭证已过期'))
    } else if (err.name === 'JsonWebTokenError') {
      return next(createError(401, '身份凭证不合法'))
    }
    next(createError(403, '无权访问当前资源'))
  }
}

额外排查建议 #

如果修复后仍验证失败，可以按以下顺序排查：

• 确认签发和验证用的公私钥是配对生成的
• 确认读取密钥文件时没有额外的换行、空格等冗余字符，打印privateKey和publicKey确认内容和pem文件完全一致
• 确认签发时的payload中没有超出JWT规范的特殊字符
• 确认传输过程中JWT没有被截断、修改，打印请求头拿到的token和签发返回的token对比是否完全一致

内容的提问来源于stack exchange，提问作者Martina352