Add SSO (Google / Microsoft) for account registration and sign-in #24

Closed
opened 2026-07-27 04:11:47 -07:00 by westfarn · 1 comment
Owner

Summary

Add single sign-on (SSO) so users can register and sign in with an identity provider (Google and/or Microsoft) instead of only email/password.

Blocks: ai_ml_operations/chat_backend#11 (Connect OneDrive / Google Drive as RAG document sources) — do this first. Drive OAuth should reuse the same Google / Microsoft OAuth app setup and token patterns established here.

Related:

Motivation

Self-serve registration (#31) is email/password only. SSO lowers friction for account creation and sign-in, and establishes OAuth client + secure token storage that #11 needs for OneDrive (Microsoft Graph) and Google Drive.

Proposed behavior

  1. OAuth start – Sign In / Sign Up offer “Continue with Google” and “Continue with Microsoft”; FE redirects to backend OAuth start endpoints.
  2. Callback – Backend exchanges code, creates or links a CustomUser (by verified email), issues the same JWT session the app already uses.
  3. Account linking – If email already exists (password or prior SSO), link the provider identity instead of creating a duplicate user; clear error when emails conflict in unsafe ways.
  4. Registration path – First-time SSO creates the account (company/profile defaults consistent with self-serve sign-up); then continue existing post-register flows (e.g. Stripe Checkout when required by #31).
  5. Secrets – Google + Microsoft OAuth client IDs/secrets and redirect URIs in settings / env examples; never commit secrets.

Backend requirements (chat_backend)

  • OAuth start + callback endpoints for Google and Microsoft (OIDC / OAuth2)
  • Persist linked identities (provider, subject/sub, user FK); support refresh where applicable for future Drive reuse (#11)
  • Map verified email → create or login user; emit JWT access/refresh compatible with current auth
  • Document env vars in .env.example / .env.prod.example
  • Tests: mocked provider callback → user create/login + JWT; account-link happy path; reject unverified email

Frontend requirements (chat_web_app)

  • SSO buttons on Sign In and Sign Up (consistent with existing auth UX)
  • Handle return / deep-link after OAuth (store JWT, land in app or next step e.g. Checkout)
  • Error states (denied consent, email missing/unverified, link conflict)
  • Works for web; note Capacitor / mobile redirect URI constraints if in scope

Acceptance criteria

  • User can register via Google SSO
  • User can register via Microsoft SSO
  • Existing user can sign in via linked SSO provider
  • Email collision links identity safely (no duplicate accounts)
  • JWT session matches current app auth model
  • OAuth client config documented in env examples; secrets not committed
  • Tests cover callback create/login and link flows (mocked IdP)
  • This issue is a dependency of #11 (complete before Drive connect work)

Out of scope (unless needed for MVP)

  • SAML / enterprise IdP / workspace-enforced SSO domains
  • Apple Sign In
  • Full Drive file picker / RAG ingest (see #11)
  • Replacing password auth entirely

Open questions

  • Require SSO-only for some companies later, or always optional alongside password?
  • After first SSO register, always force Stripe Checkout (#31) before app access?
  • Store refresh tokens now in a shape #11 can extend (DriveConnection vs generic OAuthIdentity)?

Notes

Prefer one shared OAuth-identity / token model so #11 does not re-implement Google/Microsoft app registration and secure storage.

## Summary Add **single sign-on (SSO)** so users can register and sign in with an identity provider (Google and/or Microsoft) instead of only email/password. **Blocks:** ai_ml_operations/chat_backend#11 (Connect OneDrive / Google Drive as RAG document sources) — do this first. Drive OAuth should reuse the same Google / Microsoft OAuth app setup and token patterns established here. Related: - Self-serve email/password sign-up + Stripe Checkout: ai_ml_operations/chat_web_app#31 - Password reset (existing): ai_ml_operations/chat_backend#1 ## Motivation Self-serve registration (#31) is email/password only. SSO lowers friction for account creation and sign-in, and establishes OAuth client + secure token storage that #11 needs for OneDrive (Microsoft Graph) and Google Drive. ## Proposed behavior 1. **OAuth start** – Sign In / Sign Up offer “Continue with Google” and “Continue with Microsoft”; FE redirects to backend OAuth start endpoints. 2. **Callback** – Backend exchanges code, creates or links a `CustomUser` (by verified email), issues the same JWT session the app already uses. 3. **Account linking** – If email already exists (password or prior SSO), link the provider identity instead of creating a duplicate user; clear error when emails conflict in unsafe ways. 4. **Registration path** – First-time SSO creates the account (company/profile defaults consistent with self-serve sign-up); then continue existing post-register flows (e.g. Stripe Checkout when required by #31). 5. **Secrets** – Google + Microsoft OAuth client IDs/secrets and redirect URIs in settings / env examples; never commit secrets. ## Backend requirements (`chat_backend`) - OAuth start + callback endpoints for Google and Microsoft (OIDC / OAuth2) - Persist linked identities (provider, subject/`sub`, user FK); support refresh where applicable for future Drive reuse (#11) - Map verified email → create or login user; emit JWT access/refresh compatible with current auth - Document env vars in `.env.example` / `.env.prod.example` - Tests: mocked provider callback → user create/login + JWT; account-link happy path; reject unverified email ## Frontend requirements (`chat_web_app`) - SSO buttons on Sign In and Sign Up (consistent with existing auth UX) - Handle return / deep-link after OAuth (store JWT, land in app or next step e.g. Checkout) - Error states (denied consent, email missing/unverified, link conflict) - Works for web; note Capacitor / mobile redirect URI constraints if in scope ## Acceptance criteria - [ ] User can register via Google SSO - [ ] User can register via Microsoft SSO - [ ] Existing user can sign in via linked SSO provider - [ ] Email collision links identity safely (no duplicate accounts) - [ ] JWT session matches current app auth model - [ ] OAuth client config documented in env examples; secrets not committed - [ ] Tests cover callback create/login and link flows (mocked IdP) - [ ] This issue is a dependency of #11 (complete before Drive connect work) ## Out of scope (unless needed for MVP) - SAML / enterprise IdP / workspace-enforced SSO domains - Apple Sign In - Full Drive file picker / RAG ingest (see #11) - Replacing password auth entirely ## Open questions - Require SSO-only for some companies later, or always optional alongside password? - After first SSO register, always force Stripe Checkout (#31) before app access? - Store refresh tokens now in a shape #11 can extend (`DriveConnection` vs generic `OAuthIdentity`)? ## Notes Prefer one shared OAuth-identity / token model so #11 does not re-implement Google/Microsoft app registration and secure storage.
Author
Owner
Blocks: ai_ml_operations/chat_backend#11 — https://git.aimloperations.com/ai_ml_operations/chat_backend/issues/11 Related FE sign-up: ai_ml_operations/chat_web_app#31 — https://git.aimloperations.com/ai_ml_operations/chat_web_app/issues/31
westfarn added a new dependency 2026-07-27 04:12:52 -07:00
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Reference: ai_ml_operations/chat_backend#24