fix(web): reject OAuth account-linking when no signed-in session

If a user clicks "Connect Bitbucket" and their session-token cookie is
missing or expired by the time the BB redirect arrives at our callback,
@auth/core silently falls through to createUser and mints a new orphan
User row from the OAuth profile. The orphan has no email, no UserToOrg,
and the user's session cookie gets rebound to it, leaving them on a
"request access" page.

Add a signIn callback that calls auth() and refuses the request when
the provider's purpose is account_linking and no session is present.
SSO providers and credentials login are unaffected.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: msukkari

CHANGELOG.md

@@ -12,6 +12,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - [EE] Fixed issue where repo permissions could go stale when an upstream endpoint returned HTTP 410 Gone (e.g. Bitbucket Cloud's CHANGE-2770). [#1216](https://github.com/sourcebot-dev/sourcebot/pull/1216)
 - [EE] Fixed Bitbucket Cloud account-driven permission sync after Atlassian's CHANGE-2770 removed `GET /2.0/user/permissions/repositories`. [#1217](https://github.com/sourcebot-dev/sourcebot/pull/1217)
 - Fixed issue where session invalidation (signout, user deletion, removal from org) was not reflected by `/api/auth/session`. [#1219](https://github.com/sourcebot-dev/sourcebot/pull/1219)
+- Fixed issue where an OAuth account-linking attempt without a valid signed-in session would silently create an orphan User row instead of rejecting the request.
 ## [4.17.2] - 2026-05-16
 
 ### Added

packages/web/src/auth.ts

@@ -239,6 +239,44 @@ const nextAuthResult = NextAuth({
         }
     },
     callbacks: {
+        // Refuse OAuth signin for providers configured purely for account
+        // linking when no authenticated user is present on the request.
+        //
+        // Background: @auth/core's handleLoginOrRegister (callback/handle-login.js)
+        // reads the session token from the request and, if it can't decode it
+        // (e.g., the session cookie expired browser-side while the user was
+        // mid-OAuth-dance, or it never made it across the cross-site redirect),
+        // falls through to `createUser({ ...profile })` — silently spawning a
+        // new orphan User row from the OAuth profile. That's correct behavior
+        // for `purpose: "sso"` providers (an unauthenticated user logging in
+        // via SSO should become a new Sourcebot user). It's wrong for
+        // `purpose: "account_linking"` providers: by definition, those should
+        // only ever attach an upstream identity to an *existing* signed-in
+        // user, never mint a new Sourcebot user.
+        //
+        // Returning `false` here short-circuits the callback action with an
+        // `AccessDenied` before handleLoginOrRegister can run, redirecting
+        // the user to the error page instead of leaving them stranded as a
+        // new orphan identity with no UserToOrg row.
+        async signIn({ account }) {
+            if (!account || (account.type !== 'oauth' && account.type !== 'oidc')) {
+                return true;
+            }
+
+            const matchingProvider = getProviders().find((p) => {
+                const providerId = typeof p.provider === 'function'
+                    ? p.provider().id
+                    : p.provider.id;
+                return providerId === account.provider;
+            });
+
+            if (matchingProvider?.purpose !== 'account_linking') {
+                return true;
+            }
+
+            const session = await auth();
+            return session !== null;
+        },
         // Restrict post-auth redirects (sign-in / sign-out, `callbackUrl`,
         // `redirectTo`) to the same origin as the application. This mirrors
         // Auth.js's documented default; we set it explicitly so the protection