[wobsoriano]

Description

Stacked on #10437.

with sso, navigate to task on after sign-up still fails some attempts after #10437. The provider leg now passes, but the browser lands on /sign-up/sso-callback and the organization Continue button never shows. In the Next.js 15 job on #10437 the test failed 4 times this way before it passed on the last retry.

with-session-tasks.js registers the E2E OAuth Provider with consentScreenEnabled: false. Without a consent screen, the provider skips POST /v1/me/oauth/consent/, which is where setupTestingTokens adds the app's testing token to the callback redirect. The browser goes from GET /oauth/authorize/continue straight to the app's /v1/oauth_callback with no testing token, so Protect challenges the app's sign-up and the page stays on "Verifying your request".

setupTestingTokens now handles GET /oauth/authorize/continue the same way as the consent POST. It fetches the request without following redirects and adds the destination instance's token when the Location header points at /v1/oauth_callback. The handler adds a token to the request itself only for /v1/ paths, so the provider's /oauth/authorize/continue request goes out unchanged. with-legal-consent.js disables the consent screen the same way and gets the same fix.

integration/tests/testing-token.test.ts adds a case for the authorize redirect, with tokens registered for both the app and the provider. The SSO sign-up test in session-tasks-sign-up.test.ts now asserts that the real /v1/oauth_callback request carries __clerk_testing_token, so a missing token fails with a clear message instead of a timeout.

The fix covers the callback redirect that follows a fresh sign-in at the provider. A test that starts SSO while already signed in at the provider would get the callback redirect from /oauth/authorize or /oauth/authorize-with-immediate-redirect instead, and setupTestingTokens does not stamp those. No current test does this, because each test clears cookies and signs in fresh.

Checklist

• pnpm test runs as expected.
• pnpm build runs as expected.
• (If applicable) JSDoc comments have been added or updated for any package exports
• (If applicable) Documentation has been updated

Type of change

• 🐛 Bug fix
• 🌟 New feature
• 🔨 Breaking change
• 📖 Refactoring / dependency upgrade / documentation
• other: integration test fixtures

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
clerk-js-sandbox	Ready	Preview	Oct 26, 2026 10:30pm UTC
swingset	Ready	Preview	Oct 26, 2026 10:30pm UTC

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

Run configuration

• Source mode: Auto
• Repository: clerk/javascript
• Branch: rob/e2e-oauth-callback-testing-token
• File: .coderabbit.yaml
• Commit: a7d8b74
• Layers: Repository YAML (base), Organization UI (inherited)
• Review profile: ASSERTIVE
• Plan: Team
• Run ID: 5a0c9fad-964b-414e-8d26-87f9d5d6ada5

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[changeset-bot]

🦋 Changeset detected

Latest commit: a7d8b74

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 0 packages

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[mwickett]

Fix checks out against clerk_go: with consent off, GET /oauth/authorize/continue goes through fosite's WriteAuthorizeResponse, which writes a 303 to the redirect URI, so the existing 303 + /v1/oauth_callback check catches it. Ran testing-token.test.ts locally on e96ba90: 13/13 pass, and the new case fails against the #10437 version of the helper.

One test gap: the new case registers a token only for the app origin, so expect(authorizeTokens).toEqual([null]) passes even without the /v1/ gate (I removed the gate and the test still passed). In the real E2E, #10437 registers the provider's origin too, and that's the case the gate is for. Registering the provider in the test closes it:

test('delivers the token on the callback when the provider skips the consent screen', async ({ page, context }) => {
  await setupTestingTokens({ context, frontendApiOrigin: providerOrigin, token: 'provider-testing-token' });

With that line the test fails without the gate and passes with it.

Non-blocking: this covers the replay after the user signs in at the provider. If a test ever starts SSO while already signed in there, the provider 303s to the callback straight from /oauth/authorize (or /oauth/authorize-with-immediate-redirect on dev instances) and nothing stamps it. No current test does that, since they all clear cookies and sign in fresh, so a short comment on the matcher saying why /oauth/authorize/continue is the path that matters would cover it.