调用JWT.verify时的实际过程解析：JWT签名与加密的区别解惑

核心结论先明确 #

JWT（包括Bearer令牌）不是加密机制，而是基于签名的身份验证方案，其载荷（Payload）只是用Base64Url编码的明文，任何人都能直接解码，签名的作用是防止内容被篡改。

你的疑问逐一解答 #

1. Bearer令牌/签名是否属于加密？

完全不属于。JWT由三部分组成，全部以.分隔：

• Header：Base64Url编码的JSON，包含签名算法（比如HS256即HMAC-SHA256）
• Payload：Base64Url编码的JSON，存储用户ID、权限等非敏感数据
• Signature：用Header指定的算法，结合密钥对Header.Base64Url + "." + Payload.Base64Url计算出的哈希值

前两部分都是可逆的编码（不是加密），只要用Base64Url解码就能拿到原始内容；签名是不可逆的哈希运算，无法从签名反推出原始数据。

2. 验证时具体使用签名的哪一部分？

验证过程会用到JWT的全部三部分：

• 先拆分出Header、Payload、Signature三个部分
• 用Header和Payload重新计算签名，再和JWT自带的Signature比对
• 只有两者完全一致，才说明Header和Payload没有被篡改，验证通过

3. 是否是将头部和载荷重新进行签名运算，再与附带的签名进行比对？

是的，这就是jwt.verify的核心逻辑，详细步骤如下：

1. 拆分传入的JWT令牌为headerEncoded、payloadEncoded、signatureEncoded三部分
2. 将headerEncoded + "." + payloadEncoded拼接成字符串
3. 使用Header中指定的算法（比如HS256），结合密钥（你的代码里是process.env.ACCESS_TOKEN_SECRET）重新计算哈希签名
4. 把重新计算出的签名和JWT自带的signatureEncoded进行比对
5. 如果比对一致，说明内容未被篡改，此时将payloadEncoded进行Base64Url解码，得到你代码里的user变量；如果不一致，返回验证错误

结合你的代码示例说明 #

你代码里的jwt.verify返回的user，并不是“解密”出来的，而是验证签名通过后，对Payload部分进行Base64Url解码得到的明文数据。因为只有签名验证通过，才能确保这个Payload是由持有密钥的服务端签发的，没有被篡改过，所以可以安全地把它赋值给req.user供后续使用。

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