深入理解Express中JWT验证的403错误：HTTP头部的陷阱-js教程-PHP中文网

深入理解Express中JWT验证的403错误：HTTP头部的陷阱

DDD

发布： 2025-11-16 14:50:02

原创

398人浏览过

深入理解Express中JWT验证的403错误：HTTP头部的陷阱

本文旨在解决express应用中jwt验证常见的403（forbidden）错误，尤其是在尝试访问受保护路由时遇到“a token is required”或“invalid token”的问题。核心在于揭示express如何处理http请求头，特别是将authorization头自动转换为全小写的authorization。文章将提供详细的验证中间件代码示例，并指导开发者如何正确地从请求头中提取jwt，确保api的认证流程顺畅。

理解JWT认证流程与常见问题

在现代Web应用中，JSON Web Token (JWT) 已成为一种流行的认证机制，用于在客户端和服务器之间安全地传输信息。当客户端向受保护的API端点发送请求时，通常会在HTTP请求头中附带一个JWT。服务器端的认证中间件负责解析这个JWT，验证其有效性，并据此决定是否允许请求继续处理。

然而，开发者在使用Express框架实现JWT验证时，常会遇到403（Forbidden）或401（Unauthorized）错误，并伴随着“A token is required”或“Invalid token”等提示。这通常不是JWT本身的问题，也不是客户端发送请求的方式有误，而是服务器端中间件在获取请求头信息时存在细微的偏差。

客户端请求示例

以下是一个典型的客户端（例如使用Axios）发送包含JWT的POST请求的代码示例：

import Cookies from 'js-cookie'; // 假设token存储在cookie中
import axios from 'axios';

const token = Cookies.get("token"); // 从cookie获取JWT

const checkout = () => {
  axios({
    method: "post",
    url: "http://localhost:4000/api/payment/create-checkout-session",
    headers: {
      'Content-Type': 'application/json',
      'Accept': 'application/json',
      "Authorization": "Bearer " + token, // 正确设置Authorization头
    }
  }).then(response => {
    // 处理成功响应
    if (response.status === 200) {
        return response.data;
    }
    return Promise.reject(response.data);
  })
  .then(({ url }) => {
    window.location = url;
  })
  .catch(error => {
    console.error("Checkout error:", error);
  });
};

登录后复制

从上述代码可以看出，客户端明确地在headers中设置了"Authorization": "Bearer " + token。这符合HTTP标准，并且看起来是正确的。

服务器端JWT验证中间件

接下来，我们来看一个常见的Express JWT验证中间件实现：

const jwt = require('jsonwebtoken'); // 引入jsonwebtoken库

const verifyToken = (req, res, next) => {
    // 尝试从请求体、查询参数或请求头中获取token
    const token = req.body.token || req.query.token || req.headers['Authorization'];
    console.log("Token received in middleware: ", token); // 调试输出

    if (!token) {
      return res.status(403).send("A token is required"); // 如果没有token，返回403
    }

    try {
      // 验证token
      const decoded = jwt.verify(token, process.env.JWT_SECRET);
      req.user = decoded; // 将解码后的用户信息存储在req.user上
      next(); // 继续处理请求
    } catch (err) {
      // token无效，返回401
      return res.status(401).send("Invalid token: " + err.message);
    }
};

module.exports = verifyToken;

登录后复制

这个中间件的逻辑也很清晰：它尝试从几个可能的位置获取token，如果获取不到则返回403；如果获取到则使用jwt.verify进行验证，成功后将解码信息挂载到req.user并调用next()，失败则返回401。

问题的根源：Express对HTTP头的处理

尽管客户端发送的Authorization头是大写的，并且服务器端中间件也尝试通过req.headers['Authorization']来获取，但实际上，Express（以及Node.js的HTTP模块）会将所有传入的HTTP请求头名称转换为小写。这意味着，无论客户端发送的是Authorization、authorization还是AUTHORIZATION，在Express的req.headers对象中，它们都将以小写的authorization键值对形式存在。

我们可以通过一个简单的Express应用来验证这一点：

import express from "express";

const app = express();

app.listen(3000, () => {
  console.log("Server listening on port 3000");
});

app.post("/auth", (req, res) => {
  console.log("Received headers:", req.headers); // 打印所有接收到的请求头
  res.status(200).json(req.headers);
});

登录后复制

当你使用curl命令发送一个包含大写Authorization头的请求时：

curl --header "Authorization: Bearer my_secret_token" -X POST http://localhost:3000/auth

登录后复制

服务器端console.log(req.headers)的输出将是：

{
  "host": "localhost:3000",
  "user-agent": "curl/7.79.1",
  "accept": "*/*",
  "authorization": "Bearer my_secret_token" // 注意这里是小写
}

登录后复制

这明确显示了Authorization头被转换成了小写的authorization。

百度文心百中

百度大模型语义搜索体验中心

查看详情

解决方案：正确获取请求头

知道了问题的根源，解决方案就非常简单了：在验证中间件中，应该使用req.headers.authorization（或req.headers['authorization']）来获取JWT。

修正后的JWT验证中间件：

const jwt = require('jsonwebtoken');

const verifyToken = (req, res, next) => {
    // 优先从Authorization头中获取token
    let token = req.headers.authorization; 

    // 如果Authorization头存在，且以"Bearer "开头，则提取实际token
    if (token && token.startsWith('Bearer ')) {
        token = token.slice(7, token.length); // 移除"Bearer "前缀
    } else {
        // 如果Authorization头不存在或格式不正确，则尝试从body或query中获取（作为备用方案）
        token = req.body.token || req.query.token;
    }

    console.log("Extracted Token: ", token); // 调试输出

    if (!token) {
      return res.status(403).send("A token is required for authentication.");
    }

    try {
      const decoded = jwt.verify(token, process.env.JWT_SECRET);
      req.user = decoded;
      next();
    } catch (err) {
      return res.status(401).send("Invalid Token: " + err.message);
    }
};

module.exports = verifyToken;

登录后复制

关键改动点：

将req.headers['Authorization']改为req.headers.authorization。
在获取到authorization头后，通常需要检查它是否以Bearer开头，并去除这个前缀以获取纯净的JWT字符串。

注意事项与最佳实践

统一Token来源： 虽然在中间件中尝试从body、query和headers获取token可以增加灵活性，但在生产环境中，通常建议只从Authorization头（使用Bearer方案）获取token，以保持API设计的规范性和安全性。
错误信息： 返回给客户端的错误信息应清晰但不要泄露过多敏感信息。例如，Invalid Token比Invalid token: secret or public key must be provided更合适。
JWT_SECRET： process.env.JWT_SECRET必须是一个强随机字符串，并且妥善保存在环境变量中，绝不能硬编码在代码中。
中间件顺序： 确保verifyToken中间件在需要认证的路由之前被调用。

Express Router： 如果你使用Express Router，可以将中间件应用于特定的路由组：

const router = require('express').Router();
const verifyToken = require('./verifyToken'); // 你的中间件文件

router.post("/create-checkout-session", verifyToken, async (req, res) => {
  // 只有通过验证的请求才能到达这里
  // req.user 包含了JWT解码后的信息
  const { items } = req.body;
  // ... 处理支付逻辑
});

module.exports = router;

登录后复制

总结

在Express应用中处理JWT认证时，遇到403或401错误常常是由于对HTTP请求头处理机制的误解。核心在于Express会将所有传入的HTTP请求头名称转换为小写。因此，在认证中间件中，务必使用req.headers.authorization（小写）来获取Authorization头的值，并正确提取Bearer令牌。通过遵循这些指导原则和最佳实践，可以有效地构建安全且健壮的JWT认证系统。

以上就是深入理解Express中JWT验证的403错误：HTTP头部的陷阱的详细内容，更多请关注php中文网其它相关文章！