JWT在API身份认证中已经非常普遍，但它的安全性高度依赖配置细节。一个看似正常的令牌如果使用了弱密钥、允许alg为none或者忽略了过期时间校验，攻击者就能直接伪造身份。把JWT安全配置纳入自动化测试，可以在代码合并前发现这些问题，而不是等到上线后被渗透测试报告打回。
JWT结构与常见安全配置缺陷
JWT由Header、Payload、Signature三部分组成，每部分使用Base64URL编码后用点号连接。Header声明签名算法和令牌类型，Payload承载用户身份和声明，Signature由服务端密钥对前两部分计算得出。服务端验证时必须先校验签名，再决定是否信任Payload里的内容。这个顺序一旦颠倒，攻击者就可以随意篡改声明。
自动化测试需要覆盖的缺陷通常集中在几个点。第一种是alg值为none，某些JWT库在兼容旧实现时会跳过签名校验，构造一个签名部分为空的令牌就能通过。第二种是HS256弱密钥，攻击者可以用字典或暴力猜解密钥，所以测试要使用常见弱密钥尝试签发令牌并确认被拒绝。第三种是算法混淆，当服务端同时支持非对称和对称算法时，可能导致用公钥当作HMAC密钥来验签。第四种是过期时间与声明校验缺失，比如没有检查exp、nbf、issuer和audience，令牌一旦签发就永久有效，或者跨系统复用。理解这些缺陷后，测试用例就可以围绕它们展开。
用Node.js搭建JWT安全测试环境
在Node.js项目里，推荐使用supertest驱动API请求，搭配Jest或Mocha组织断言。jsonwebtoken负责生成正常和异常令牌，也可以直接手动构造JWT来绕过某些库的签名限制。测试环境需要能注入不同的JWT配置，例如环境变量JWT_SECRET同时设置正常密钥和弱密钥，以便在同一个测试套件中对比服务端行为。
下面是一个辅助函数，用来生成带指定算法和过期时间的JWT，方便后续测试重复使用。
const jwt = require('jsonwebtoken');
function createToken(payload, secret, options) {
const merged = Object.assign({ algorithm: 'HS256' }, options);
return jwt.sign(payload, secret, merged);
}
function createNoneToken(payload) {
const header = Buffer.from(JSON.stringify({ alg: 'none', typ: 'JWT' })).toString('base64url');
const body = Buffer.from(JSON.stringify(payload)).toString('base64url');
return header + '.' + body + '.';
}
module.exports = { createToken, createNoneToken };
这个文件只负责构造令牌，不关心API实现。对于Express应用，可以用supertest直接挂载app；对于远程服务，也可以让supertest指向测试环境地址。测试文件里使用beforeAll或beforeEach准备请求实例，保持用例隔离。
关键安全测试用例实现
第一个用例检查alg为none的令牌是否被服务端拒绝。攻击者会构造一个没有签名的JWT，将Payload中的sub改为管理员用户。此时服务端如果直接接受，等于任何人可以无密钥冒充身份。测试断言状态码不能是200或业务数据不能正常返回，具体取决于接口约定。
const request = require('supertest');
const app = require('../app');
const { createNoneToken } = require('./helpers');
describe('JWT alg none', function () {
it('should reject token with alg none', async function () {
const token = createNoneToken({ sub: 'admin', role: 'admin' });
const res = await request(app)
.get('/api/profile')
.set('Authorization', 'Bearer ' + token);
expect(res.status).not.toBe(200);
expect(res.status).toBe(401);
});
});
第二个用例围绕弱密钥展开。很多服务为了方便，使用secret、password、123456这类容易猜的密钥。测试可以维护一个常见弱密钥列表，依次签出合法格式的令牌，再请求受限接口。只要任何一个被接受，就说明服务端使用了弱密钥或者没有做密钥强度校验。这类测试对代码质量要求不高，但能阻止明显配置错误上线。
const request = require('supertest');
const app = require('../app');
const jwt = require('jsonwebtoken');
describe('JWT weak secret', function () {
const weakSecrets = ['secret', 'password', '123456', 'jwt-secret'];
weakSecrets.forEach(function (secret) {
it('should reject token signed with weak secret: ' + secret, async function () {
const token = jwt.sign({ sub: 'admin' }, secret, { algorithm: 'HS256' });
const res = await request(app)
.get('/api/profile')
.set('Authorization', 'Bearer ' + token);
expect(res.status).toBe(401);
});
});
});
第三个用例验证过期令牌和签名错误令牌是否会被正确拦截。过期令牌可以直接使用expiresIn为负数生成；签名错误令牌用另一个密钥签发。两者都应返回401，如果返回200说明服务端没有验证签名或没有检查过期时间。过期时间还需要注意服务端与客户端之间的时钟偏移，测试可以设置一个刚刚过期几秒的令牌，避免缓存或时间精度造成误判。
const request = require('supertest');
const app = require('../app');
const jwt = require('jsonwebtoken');
describe('JWT expiry and signature', function () {
it('should reject expired token', async function () {
const token = jwt.sign({ sub: 'user1' }, 'correct-secret', { algorithm: 'HS256', expiresIn: '-10s' });
const res = await request(app)
.get('/api/profile')
.set('Authorization', 'Bearer ' + token);
expect(res.status).toBe(401);
});
it('should reject token signed with wrong secret', async function () {
const token = jwt.sign({ sub: 'user1' }, 'wrong-secret', { algorithm: 'HS256' });
const res = await request(app)
.get('/api/profile')
.set('Authorization', 'Bearer ' + token);
expect(res.status).toBe(401);
});
});
还可以围绕issuer和audience编写用例。服务端如果配置了期望的issuer和audience，测试就应该生成不匹配的令牌，确认被拒绝。这个校验能防止一个业务系统的令牌被另一个系统直接复用。自动化用例中可以把issuer设置为其他域，audience改为其他客户端ID，断言响应为非授权状态。相比手动抓包验证，自动化测试能持续覆盖这些细节。
将JWT安全测试接入CI/CD与最佳实践
JWT安全测试的价值在于持续执行。可以把这些用例放到项目的npm test命令中，配置到GitHub Actions、GitLab CI或Jenkins流水线，每次提交和合并请求时自动运行。测试失败就阻断合并，避免不安全配置流入主干。对于已有项目，可以先从核心接口开始，逐步增加弱密钥和算法混淆用例，不需要一次性覆盖所有接口。
修复思路也要配合测试落地。密钥改为密码学安全的随机字符串，至少256位，HS256密钥长度与哈希输出一致。生产环境优先使用RS256或ES256非对称算法，私钥只保存在服务端，公钥分发给验证方。令牌过期时间尽量短，例如15分钟到1小时，并配合刷新机制。不要在Payload中写入密码、身份证号等敏感信息，因为Payload只是Base64URL编码，任何人可解码。测试不是目的，让配置持续保持在安全状态才是最终目标。
如果服务端使用多个JWT库或网关层，还要避免不同组件对alg和声明的解析差异。自动化测试应覆盖直接请求和经过网关的路径，确保每个入口都执行相同的校验逻辑。把JWT安全配置测试纳入常规开发流程后，大部分身份伪造和越权风险可以在上线前被拦截，安全团队也能把精力集中在更复杂的业务逻辑漏洞上。