3.5 KiB
Phase 8: Social Sign-in - Discussion Log
Audit trail only. Do not use as input to planning, research, or execution agents. Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.
Date: 2026-05-15 Phase: 8-Social Sign-in Areas discussed: Account linking, Social-only accounts, Login/signup surface, Provider profile data
Account Linking
| Option | Description | Selected |
|---|---|---|
| Auto-link verified email | If provider email is verified and matches an existing user, attach provider identity and sign them in. | ✓ |
| Require current password first | Matching email lands on a confirm-password step before linking. | |
| Only link while already signed in | Social login creates a separate account unless explicitly linked from account settings. |
User's choice: Auto-link verified email. Notes: Missing or unverified provider email is rejected with a clear error. If a provider subject is already linked, provider identity wins over later email changes. Add a simple linked providers status view; unlinking is deferred.
Social-Only Accounts
| Option | Description | Selected |
|---|---|---|
| Allow passwordless users | Make users.password_hash nullable; social users can exist without passwords. |
✓ |
| Generate unusable password hash | Keep password_hash NOT NULL with a sentinel hash. |
|
| Require setting password after social signup | Social signup creates account, then immediately asks user to set password. |
User's choice: Allow passwordless users. Notes: Adding a password later is deferred. Email/password signup is blocked if a social-only account already owns that email. Existing password users linked to Google/Apple keep password login.
Login/Signup Surface
| Option | Description | Selected |
|---|---|---|
| Both login and signup pages | Same provider buttons on both pages; callback handles create/link/sign-in. | ✓ |
| Login page only | Treat social auth as sign-in, with account creation implicit after callback. | |
| Signup page only | Use social only for account creation. |
User's choice: Both login and signup pages.
Notes: Show disabled provider buttons when config is missing. Google and Apple get equal prominence. Successful social sign-in redirects to /.
Provider Profile Data
| Option | Description | Selected |
|---|---|---|
| Minimal identity only | Store provider, subject, email, email_verified, and timestamps only. | |
| Store display name too | Persist provider name where available. | |
| Store name and avatar | Persist provider name and profile image URL where available. | ✓ |
User's choice: Store name and avatar.
Notes: User first answered minimal identity, then explicitly returned to this question and changed the answer to store name and avatar. Apple private relay emails are accepted as verified if Apple verifies them. Provider identity email and local users.email should update when provider verified email changes.
the agent's Discretion
- Exact database field names and route names.
- Exact disabled-provider and provider-error copy.
- Exact handling of local email update conflicts, provided it does not silently overwrite or relink another account.
Deferred Ideas
- Provider unlink actions.
- Add-password/password management for social-only users.
- Password reset flow.
- Redirect-after-login return URL through OAuth state.