fix(web): reject OAuth account-linking without a signed-in session

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)
+- [EE] 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. [#1221](https://github.com/sourcebot-dev/sourcebot/pull/1221)
 ## [4.17.2] - 2026-05-16
 
 ### Added

packages/web/src/auth.ts

@@ -129,7 +129,7 @@ export const getProviders = () => {
                     } else {
                         if (!user.hashedPassword) {
                             return null;
-                        }
+                    }
 
                         if (!bcrypt.compareSync(password, user.hashedPassword)) {
                             return null;
@@ -239,6 +239,38 @@ const nextAuthResult = NextAuth({
         }
     },
     callbacks: {
+        async signIn({ account }) {
+            const matchingProvider = account
+                ? getProviders().find((p) => getEffectiveProviderId(p.provider) === account.provider)
+                : undefined;
+
+            // 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 mid auth flow, 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.
+            const isAccountLinkingAttempt = matchingProvider?.purpose === 'account_linking';
+            const session = await auth();
+            if (isAccountLinkingAttempt && session === null) {
+                return false;
+            }
+
+            return true;
+        },
         // 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
@@ -367,18 +399,29 @@ export const auth = cache(async (): Promise<Session | null> => {
     return nextAuthResult.auth();
 });
 
+// NextAuth/Auth.js provider factories (e.g. Bitbucket, GitHub, GitLab) hardcode
+// a default `id` at the top of the returned object and nest the caller's
+// options (including any `id` override) under `.options`. At runtime the
+// framework merges options over the top-level defaults, so the effective
+// provider id can live under either field depending on whether the caller
+// passed an override. Read `.options.id` first and fall back to the top-level
+// `id`. The function form of `Provider` is part of the NextAuth type union but
+// unused in this codebase; we handle it for type completeness.
+const getEffectiveProviderId = (provider: Provider): string | undefined => {
+    const config = (
+        typeof provider === 'function'
+            ? (provider as unknown as () => unknown)()
+            : provider
+    ) as { id?: string; options?: { id?: string } };
+    return config.options?.id ?? config.id;
+}
+
 /**
  * Returns the issuer URL for a given auth.js account
  */
 const getIssuerUrlForAccount = async (account: { provider: string; }) => {
-    const providers = getProviders();
-    const matchingProvider = providers.find((provider) => {
-        if (typeof provider.provider === "function") {
-            const providerInfo = provider.provider();
-            return providerInfo.id === account.provider;
-        } else {
-            return provider.provider.id === account.provider;
-        }
-    });
+    const matchingProvider = getProviders().find(
+        (p) => getEffectiveProviderId(p.provider) === account.provider
+    );
     return matchingProvider?.issuerUrl;
 }