fix(auth): let the OAuth provider resume authorization after sign-in

[codemancers-bot]

An MCP client sending a user through /oauth2/authorize got them as far as the login page, then dropped them at /chat instead of the consent screen — so the client waited on a callback that never arrived. Plus one unrelated install fix.

Why it broke

better-auth's oauth-provider resumes an interrupted authorization on its own. Per the plugin docs:

You don't need to handle anything from your side; when a new session is created, the plugin will handle continuing the authorization flow.

The mechanism, in the installed 1.6.22:

1. oauthProviderClient() attaches the signed authorization query to non-GET auth requests as oauth_query (dist/client.mjs).
2. A server before hook verifies it and stashes it (dist/index.mjs:2992); for /sign-in/social it also copies it into additionalData.query so it survives the trip through Google.
3. A server after hook fires on any response that sets a session cookie, re-runs runOAuth2Authorize, and returns {redirect, url} pointing at consent (dist/index.mjs:3019).
4. The client's own redirectPlugin navigates on that shape (better-auth/dist/client/fetch-plugins.mjs).

The sign-in form bypassed all of it: no callbackURL, so responses came back redirect: false, and it hand-rolled navigation with router.push('/chat'). When the plugin did resume, that push raced it.

What changed

Use callbackURL instead of hand-rolled navigation. signIn.email populates {redirect, url} straight from it (api/routes/sign-in.mjs:253), so one mechanism covers both normal logins and MCP consent. followOAuthResume and redirectAfterAuth are gone.

Resume across a social login. The Google button is the only sign-in control production renders (see Reachability below), and it named a fixed destination. A social login leaves for Google before there's a response for the plugin to rewrite, so callbackURL is now computed: when the signed query is still on the URL it points back at the authorize endpoint, otherwise /chat.

It points at the same-origin /auth proxy, not BACKEND_URL. Web and api are sibling *.fly.dev hosts with no shared cookie domain, so hitting the backend authorize endpoint directly would carry no session and bounce straight back to the login page. The proxy forwards the cookie. Re-encoding the query in transit is safe — the signature is verified over a canonicalised, re-sorted URLSearchParams on both sides (version-DaSfXJQ1.mjs:5).

Decide where a login belongs at the app's door. callbackURL must be a fixed URL, but the destination depends on state that exists only once there's a session. chat/layout.tsx already validated the session server-side; it now also checks activeOrganizationId and routes to invitations or organization creation. This closes a gap that predates the PR: someone with no organization navigating straight to /chat was let in, and every request they made failed with NO_ACTIVE_ORGANIZATION.

No loop — activeOrganizationId is stamped at session creation and refreshed by setActive on organization create (create-org.tsx) and invitation accept (user-invitations.tsx).

Carry the authorization query across the sign-up link. oauthProvider has only loginPage, so the signed query lands on /sign-in; the link to /sign-up was bare and dropped it, leaving a new user unable to resume. Also stops the form re-enabling its submit button mid-navigation.

Remove COOKIE_DOMAIN. Added in 0498e59 so the direct browser → backend authorize hit would see the session — unnecessary, since an unauthenticated authorize request is the expected state and bounces to the login page by design. It could not have worked anyway: fly.dev is a public suffix, so browsers reject the Domain attribute, and the /auth proxy strips domain= from every Set-Cookie. A comment points at advanced.crossSubDomainCookies for the day web and api share a registrable domain.

Describe every scope on the consent screen. It described relations:*, which aren't in MCP_SCOPES, while ten scopes that are — icps, leads, campaigns, comments, prospects — rendered as raw strings like prospects:write on the screen where users decide what to grant. All 19 now have descriptions, verified in both directions.

Stop sharp attempting a source build (unrelated). Its install script is node install/check.js || npm run build, and check.js exits 1 whenever it detects a system libvips (lib/libvips.js:176) — true on any host with libvips-dev or Homebrew libvips. That exit selects the source-build fallback, which dies on sharp: Please add node-gyp to your dependencies. Cosmetic so far, since the binary comes from the @img/sharp-* optional deps, but noise on every install and a hard failure on any platform without a prebuild. sharp: false in allowBuilds, matching the existing @scarf/scarf: false precedent.

Reachability — read before assuming this unblocks the reported bug

The email/password form is gated behind NEXT_PUBLIC_BETTER_AUTH_INCLUDE_EMAILS_AUTH (flags.ts, defaultValue: false). NEXT_PUBLIC_* is inlined at build time, and apps/web/Dockerfile passes no build arg and copies no .env — the local build output shows decide baked to a constant. So in the Fly image it is false permanently, and checking the prod env var tells you nothing; enabling it needs a Dockerfile ARG, not a secret.

That makes Google the only live sign-in path, which is what the social-login commit addresses.

Testing

The sharp change is verified: frozen-lockfile install, no build attempt, no ignored-scripts warning, pendingBuilds empty, lockfile unchanged, require('sharp') still loading libvips 8.17.3. The original failure was reproduced beforehand with SHARP_FORCE_GLOBAL_LIBVIPS=1.

The auth changes are not verified end-to-end. A full local run of the MCP flow (discovery → registration → authorize → sign-in → consent → token → tools/call) passed on an earlier commit of this branch, but only via email/password; the Google path has not been exercised. npx tsc --noEmit -p apps/web/tsconfig.json was OOM-killed in the dev environment, so changed files were verified to transform cleanly under esbuild instead.

CI has skipped every run on this branch. The ci job is gated on author_association being OWNER/MEMBER/COLLABORATOR; the REST API reports this PR's author as MEMBER, but the webhook payload reflects public org membership, so a bot with private membership reads as CONTRIBUTOR and the job never runs. Worth fixing separately — either make the membership public or add an explicit actor check.

Given all of the above, exercise normal sign-in, invited-user, and no-organization-yet flows before merging. [AUTH PROXY] Redirect to: in the web app's logs shows what the Google callback actually resolves to.

Known gaps, not addressed here

• A brand-new user completing consent still has no organization, so every MCP tool call fails with NO_ACTIVE_ORGANIZATION. Gating consent behind organization creation needs a resume-after-create mechanism that doesn't exist yet.
• When a client omits the RFC 8707 resource param the provider mints an opaque token rather than a JWT (dist/index.mjs:510), and McpBearerGuard rejects it with a misleading "Invalid or expired access token". Worth distinguishing "not a JWT" from "JWT failed verification".

🤖 Generated with Claude Code