fix(account): resume oauth2 flow after login/register on cloud IdP

When better-auth's oauth-provider redirects an unauthenticated user from
/oauth2/authorize to loginPage (/_account/login), it preserves the full
authorize query — client_id, redirect_uri, signed sig, state, etc. — on the
target URL. After the user authenticates we must replay those same params
back to /oauth2/authorize so the IdP can issue the code and 302 the user
home to the RP (e.g. crm.objectos.app).

Without this hand-off, the login page falls through to its default landing
(window.location.assign('/')) and the user ends up on the cloud Studio
dashboard while the RP never sees the callback — the SSO flow stalls
silently from the user's perspective.

Detect the flow via the presence of `client_id` + `redirect_uri` query
params (the signed `sig` would also work but these are mandatory per the
authorize spec). Apply the same fix to /register so a user who chooses to
sign up mid-SSO also lands back on the RP rather than the IdP dashboard.

Consent step is already bypassed for first-party platform SSO clients
(seedPlatformSsoClient sets skip_consent=true), so the resumed authorize
call returns the code immediately.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: hotlong

apps/account/src/routes/login.tsx

@@ -61,6 +61,24 @@ function LoginPage() {
   useEffect(() => {
     if (!user) return;
 
+    // OAuth-provider hand-off: when the user landed on /login because
+    // better-auth's oauth-provider redirected them here from /oauth2/authorize
+    // (unauthenticated user starting an SSO flow), the original authorize query
+    // params — including `client_id`, `redirect_uri`, the signed `sig`, etc. —
+    // are preserved on the current URL. After login succeeds we must resume
+    // the OAuth flow by sending the same params back to /oauth2/authorize so
+    // the IdP can issue the code and 302 the user back to the RP.
+    //
+    // Without this, the user ends up on the Studio dashboard (the post-login
+    // default) and the RP never sees the callback, so the SSO flow stalls.
+    if (typeof window !== 'undefined') {
+      const sp = new URLSearchParams(window.location.search);
+      if (sp.has('client_id') && sp.has('redirect_uri')) {
+        window.location.assign(`/api/v1/auth/oauth2/authorize${window.location.search}`);
+        return;
+      }
+    }
+
     // If the user has organizations but no active one, auto-select the first
     // org before navigating away. Otherwise consumers like the Console's
     // `RequireOrganization` guard would bounce the user from the redirect

apps/account/src/routes/register.tsx

@@ -54,6 +54,18 @@ function RegisterPage() {
   useEffect(() => {
     if (!user) return;
 
+    // OAuth-provider hand-off: see apps/account/src/routes/login.tsx for the
+    // full rationale. When the user landed on /register from /oauth2/authorize
+    // we must resume the OAuth flow by replaying the signed authorize params
+    // instead of dropping them into the Studio default landing.
+    if (typeof window !== 'undefined') {
+      const sp = new URLSearchParams(window.location.search);
+      if (sp.has('client_id') && sp.has('redirect_uri')) {
+        window.location.assign(`/api/v1/auth/oauth2/authorize${window.location.search}`);
+        return;
+      }
+    }
+
     // If the freshly-signed-up user already has organizations (the auth
     // plugin auto-provisions a personal workspace, or they accepted an
     // invitation), make sure one is active before navigating away. Without