[Thirunavukkarasu]

Summary

Replaces the AWS Cognito identity provider in NextAuth with Google OAuth, so tenants sign in with Google instead of a Cognito-hosted UI.

What changed

• libs/shared/src/auth/auth-options.ts — swaps CognitoProvider for next-auth's GoogleProvider, gated on GOOGLE_CLIENT_ID. Credentials login is untouched.
• apps/web-ui/lib/env.ts, libs/shared/src/env.ts — declare GOOGLE_CLIENT_ID / GOOGLE_CLIENT_SECRET, and OLLAMA_BASE_URL. Cognito vars are kept as optional legacy so nothing else that reads them breaks.
• apps/web-ui/app/(auth)/login/page.tsx, register/page.tsx — buttons now call signIn('google') and read "Sign in / Sign up with Google".
• apps/web-ui-e2e/src/pages/sso.flow.ts — e2e SSO flow targets the Google button and no longer assumes Cognito's hosted UI.
• apps/web-ui/app/(marketing)/components/feature-grid.tsx — marketing copy updated from Cognito to Google.
• .env.example — documents Google OAuth (redirect URI http://localhost:3005/api/auth/callback/google) and the Ollama provider.
• .gitignore — ignores local .env.bak.* backups.

Notes for reviewers

• No secrets are committed. .env and its backups are gitignored; .env.example carries placeholders only.
• OLLAMA_BASE_URL is the only Ollama env var this app reads (used by libs/knowledge-base for local embeddings/reranking). Ollama chat providers and credentials are configured per-tenant in the UI (LlmProvider table), not from env.
• Cognito env vars are intentionally left declared as optional rather than deleted, since libs/shared still exports Cognito helpers (cognito-client.ts, invitation-service.ts) used elsewhere.

Testing

• nx run-many -t typecheck -p shared,web-ui — ✅ passed.
• Google sign-in verified end-to-end locally: both the login and register buttons reach Google's real consent screen (after adding http://localhost:3005/api/auth/callback/google to the OAuth client's authorized redirect URIs).

Follow-ups (not in this PR)

• Remaining docs/README references to Cognito SSO.
• libs/shared/src/services/invitation-service.ts still uses Cognito for invitation emails.

[kartikmanimuthu]

Thanks @Thirunavukkarasu — the mechanical part of this is complete and careful: provider, both T3 env schemas, login/register buttons, marketing copy, .env.example and the e2e page object all move together, and leaving the Cognito vars declared so libs/shared exports keep working was the right call. No secrets committed either. Note that the red CI on this PR is not yours — the failing step is env validation (Invalid environment variables in libs/claw-studio/src/env.ts and apps/workers/src/env.ts), the same failure main has had since early September. #62 fixes that.

Three things I'd like to settle before this ships, because it changes how every user signs in:

1. The migration is half-done. libs/shared/src/services/invitation-service.ts still sends Cognito invitations, and cognito-client.ts is still exported. After this lands, an invited user receives a link to a Cognito hosted UI that can no longer authenticate anyone. Either finish the invitation path here or gate invitations off in the same release — otherwise invites become a dead end.
2. Validate the Google pair together. The provider is gated on GOOGLE_CLIENT_ID alone, and clientSecret: env.GOOGLE_CLIENT_SECRET! is a non-null assertion. Set the ID and forget the secret and you get a provider with an undefined secret and a 500 at token exchange. A Zod .refine for both-or-neither turns that into a startup error.
3. The e2e SSO flow can't work as written (sso.flow.ts:18-20): it still fills Cognito's name@host.com / Password fields, and Google blocks automated sign-in outright ("This browser or app may not be secure"). The repo already mints real NextAuth sessions in setup/auth.setup.ts, so a seeded storageState session would be both simpler and stable.

Worth a deliberate decision, not a blocker: allowDangerousEmailAccountLinking: true. Google verifies e-mails, so it's far safer than with an arbitrary OIDC issuer — but it silently links an existing password account to a Google identity claiming that e-mail, and it routes around the lockout logic directly above it (a locked-out account can just sign in with Google). If that's intended, a note in the PR and a signIn callback that refuses linking when user.passwordHash exists would make it explicit.

Minor: the .catch(() => { }) and constructor(private readonly page: Page) { } reformatting — Prettier's output for an empty body is {}, so prettier --check would put those back. Dropping them keeps the diff about auth. Also auth-options.ts:48 still says "sign in with the SSO tab" while the button now reads "Sign in with Google".

Approving — thanks, and thanks for verifying the real consent screen end-to-end rather than trusting the config.