Suite Google login for pilot

Problem

Cloud Suite needs a real Google login path that works for the internal pilot now and can carry forward to a public launch soon after. Today the app has partial django-allauth wiring, but the task is still framed as a pilot-only SSO add-on rather than a production-ready account foundation. If Google login remains narrowly scoped to internal pilot access, the team will either rework auth during launch prep or ship with an improvised identity setup tied to ad hoc credentials, redirect URIs, and environment-specific behavior.

Context

• Cloud already uses django-allauth; Google provider wiring, login templates, and account middleware are present in the Django app.
• The right M1 outcome is a production-safe Google OAuth foundation, not just a one-off corporate login for pilot users.
• Google should be treated as the primary external-facing login path for Cloud Suite.
• Okta should remain optional and can be layered later as a secondary provider for internal Fivetran access.
• GitHub repo sync authorization is a separate concern from account login and should follow the Google login foundation rather than be bundled into it.
• The M1 goal is end-to-end login and session establishment across environments, not full role-sync automation.
• Post-login authorization, role mapping, and audit/drift follow-ups are tracked separately in suite-role-sync-and-permission-enforcement-follow-ups.md.
• Follow-on work for Okta and GitHub integration auth is tracked in suite-okta-login-via-oidc.md and github-integration-auth-for-repo-sync.md.

Possible Solutions

• Recommended: Keep django-allauth as the single auth framework, productionize the built-in Google provider, and externalize provider configuration via env vars / Secret Manager.
• Lowest churn because the app already uses allauth.
• Supports Google now and allows Okta later via OpenID Connect without introducing a second auth stack.
• Keeps user login separate from GitHub repo authorization.
• Replace allauth with a different Django auth package.
• Could work, but adds migration churn with little benefit for the current provider set of Google, Okta, and maybe GitHub.
• Build bespoke OAuth handling in the app.
• Highest control, but unnecessary complexity and more security footguns than using the established allauth provider flows.

Plan

• Productionize the existing allauth Google login flow for Cloud.
• Configure environment-safe settings for local, internal hosted, and future public domains.
• Define the required Google OAuth client setup:
• internal client and redirect URIs
• production client and redirect URIs
• minimal scopes: openid, email, profile
• Store client credentials in deploy-safe config rather than relying on manual admin-only setup.
• Make Google login work end-to-end in the hosted environment with correct session/callback behavior.
• Document the login/onboarding path for internal analysts and the later public-launch handoff.
• Keep the task explicitly limited to Google account auth; track Okta and GitHub follow-ons separately.

Implementation Progress

• Existing Cloud auth stack uses django-allauth, which makes Google the right primary provider to finish first.
• Internal/private domain and hosting work is being tracked through the GCP/internal access tasks in integrations-platform and infra-tooling.
• M1 should establish the canonical auth foundation that M2 Okta and GitHub integration-auth work can build on.

Completed

• [x] Custom DatafaceSocialAccountAdapter (apps/cloud/apps/accounts/social_adapter.py):
• populate_user: maps Google picture field to User.avatar_url
• pre_social_login: auto-connects social login to existing user with matching email (prevents duplicate accounts)
• save_user: auto-creates a personal Organization with OWNER role for first-time social signups
• [x] Settings productionized (apps/cloud/settings.py):
• Added openid to Google OAuth scopes (openid, profile, email)
• Set SOCIALACCOUNT_AUTO_SIGNUP = True so Google users skip the signup form
• Set SOCIALACCOUNT_ADAPTER to point to the custom adapter
• [x] Signup template (templates/account/signup.html):
• Added Google and GitHub social login buttons (matching the login page pattern)
• Buttons conditionally rendered via google_login_enabled / github_login_enabled context flags
• [x] Tests (tests/cloud/test_google_social_adapter.py):
• 7 unit tests covering avatar population, email matching, org creation, and skip-when-exists paths
• All 137 cloud tests passing

QA Exploration

N/A — Auth flow requires live Google OAuth credentials and a running server; the adapter logic is fully covered by unit tests. End-to-end browser QA should be done during deploy to the internal hosted environment with real Google OAuth client credentials.

• [x] QA exploration completed (or N/A for non-UI tasks)

Review Feedback

• [ ] Review cleared