如何使用supertest和jest测试OAuth2流程及Nonce报错问题

问题背景 #

开发了一款对接多类OpenID授权服务（包含Salesforce、Google登录、Teams登录等）的应用，需要实现自动化测试。当前方案采用独立模拟服务搭建认证流程环境，依赖标准OpenID Client库编写测试，现有测试代码如下：

/**
 * /AUTH TESTS
 */

describe('GET the auth route', () => {
    test('return 302 when redirect correctly', async () => {
        const response = await api
            .get('/auth')
            .query({ user: 'tester@test.com', oauth: 'testoauth2'})
            .set('Authorization', `${token}`)
            .expect(302)
    })
})

describe('GET the authcallback route', () => {
    test('return content when auth is successful', async () => {
        const response = await api
            .get('/authcallback')
            .set("Cookie", ['oauthKey=testoauth2; nonce=4DwCl4XuvRcckI_7Yv2smA0hnRxQtj2_mU1Q13NbU9A; codeVerifier=c-WoROhqZHBS13rSJ1ePd4O5p4W-_aqB1n3fJSjLXaU; user=tester@test.com' ])
            .set('Authorization', `${token}`)
            .query({
                code: "aPrxi6BfM_yOlkX6zB4nTDQCYgASP_69O.ZCuOWYNe7DyP2UxaNc5ZwtbDsPrG_wnUgvb3WJ8Q=="
            })

    })
})

待解答问题包含三个方向：supertest是否适用于OAuth2工作流测试、Nonce不匹配错误的根因、端到端测试工具选型建议。 #

1. supertest是否可用于常规场景下的OAuth2工作流测试 #

可以，但仅适用于接口层的分段逻辑校验，无法覆盖完整的端到端授权流程。
supertest的核心逻辑是直接向服务端发送构造的HTTP请求，不会模拟浏览器的跨域跳转、Cookie自动存储透传、前端页面交互等行为，因此无法复现用户从业务页触发登录、跳转到授权服务、完成授权后回跳业务系统的全链路操作，仅适合单独校验自有服务的两个核心接口逻辑：

• /auth接口是否能正确返回302跳转、是否拼接了正确的授权请求参数
• /authcallback接口在拿到合法参数时是否能正确处理、非法参数时是否返回预期错误
  如果要测完整的交互流程，仅靠supertest需要手动处理大量上下文传递逻辑，维护成本极高。

2. 测试中频繁返回「Nonce mismatch」的遗漏点 #

这个错误的核心原因是完全跳过了授权流程的上下文生成环节，硬编码了所有动态校验参数，具体遗漏点如下：

• Nonce是每次发起授权请求时动态生成的随机字符串，会同时存储在两个位置：一是写入用户当前会话的Cookie/服务端会话存储中，二是作为参数拼接在跳转授权服务的请求中，授权服务回跳时会将Nonce嵌入返回的ID Token中，服务端需要拿本地存储的Nonce和ID Token解析出的Nonce做比对。硬编码在Cookie里的Nonce是固定值，和本次请求实际生成的Nonce完全无关，必然校验失败。
• 两次测试请求完全独立，没有透传上下文：第一次调用/auth接口时，服务会在响应头的Set-Cookie字段中返回本次请求生成的Nonce、Code Verifier等会话信息，没有提取这些信息透传到第二次回调请求中，反而手动写入了假的Cookie值，服务端拿不到当前流程对应的真实Nonce，自然报匹配错误。
• 硬编码的授权码是无效值：模拟授权服务每次生成的授权码都会和当前请求的Nonce、Code Verifier做绑定，写死的授权码和硬编码的Nonce本身就没有绑定关系，哪怕Nonce值碰巧写对，授权码不匹配也会导致校验失败。

用supertest做接口层校验的正确流程：先发起/auth请求，从响应头提取Set-Cookie的会话信息、解析Location头里的授权请求参数，再调用模拟授权服务的接口生成和这些参数匹配的合法授权码，最后带着第一步拿到的真实会话Cookie、合法授权码请求/authcallback接口，才能通过校验。

3. Cypress、TestCafe是否为更优的测试方案 #

如果需要覆盖完整的授权交互流程，这类端到端测试工具确实是比supertest更优的选择：

• 这类工具会真实驱动浏览器运行，自动处理跨域跳转、Cookie存储透传、页面渲染交互等逻辑，完全模拟用户真实的登录操作路径，不需要手动解析响应头、拼接参数、维护请求上下文，从根本上避免硬编码动态参数导致的各类校验错误。
• 对接模拟授权服务的配置成本极低，只需要在测试环境将授权服务的地址配置为模拟服务地址，或者通过工具的请求拦截能力将跳转到正式授权服务的请求转发到模拟服务即可，剩下的授权参数传递、会话存储流程会由浏览器自动完成。
  实际落地建议做分层测试：用supertest做接口层的单点逻辑校验，覆盖参数校验、错误处理等不需要走完整流程的场景；用Cypress/TestCafe做端到端的全流程校验，覆盖用户真实使用的完整授权链路，兼顾测试效率和覆盖度。

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