Google 3: new accounts, and the consent problem #342

New Issue

2026-09-10T08:12:48-05:00

bermudalamb commented

2026-09-10 08:12:48 -05:00

Part of #332. Phase 3 of six. Depends on #341.

A customer with no account who signs in with Google gets one. The genuine design problem in this phase is not the OAuth.

The problem

Registration captures two consents with wording stored verbatim, and marketing consent must start unticked (#56). A customer arriving through Google has never seen those checkboxes, and cannot: the redirect happens before anyone knows whether they are new.

Creating the account with both consents false is defensible and legal. It is also a silent decision made on the customer's behalf, and it means a Google sign-up would never be asked in the normal flow.

The answer

Create the customer with both consents false, sign them in, and land them on a short one-time step showing the same two sentences and the same two unticked boxes. Skipping is allowed and leaves both false.

This keeps sign-in fast, never blocks a customer behind a form, and asks at a moment when the wording can be shown honestly. Consent given there goes through the existing endpoints, so the stored text stays byte-identical to what registration records.

Also in scope

Take given_name and family_name from the profile and treat them as hints. Google may return neither; the schema already tolerates that.
Set email_verified = true only when Google asserts it — the decision recorded on #332. Otherwise create the account unverified and issue the usual confirmation email, because an unverified assertion is worth nothing.
Create the customer and the identity in one transaction. A customer with no identity is an account nobody can sign in to.

Done when

A brand new Google account produces a customer and an identity, signed in, with both consents false and the stored consent text unchanged from what registration writes; and a second sign-in with the same Google account reaches the same customer rather than a second one.

Part of #332. Phase 3 of six. Depends on #341. A customer with no account who signs in with Google gets one. The genuine design problem in this phase is not the OAuth. ## The problem Registration captures two consents with wording stored verbatim, and marketing consent must start unticked (#56). A customer arriving through Google has never seen those checkboxes, and cannot: the redirect happens before anyone knows whether they are new. Creating the account with both consents false is defensible and legal. It is also a silent decision made on the customer's behalf, and it means a Google sign-up would never be asked in the normal flow. ## The answer Create the customer with both consents false, sign them in, and land them on a short one-time step showing the same two sentences and the same two unticked boxes. Skipping is allowed and leaves both false. This keeps sign-in fast, never blocks a customer behind a form, and asks at a moment when the wording can be shown honestly. Consent given there goes through the existing endpoints, so the stored text stays byte-identical to what registration records. ## Also in scope - **Take `given_name` and `family_name` from the profile and treat them as hints.** Google may return neither; the schema already tolerates that. - **Set `email_verified = true` only when Google asserts it** — the decision recorded on #332. Otherwise create the account unverified and issue the usual confirmation email, because an unverified assertion is worth nothing. - **Create the customer and the identity in one transaction.** A customer with no identity is an account nobody can sign in to. ## Done when A brand new Google account produces a customer and an identity, signed in, with both consents false and the stored consent text unchanged from what registration writes; and a second sign-in with the same Google account reaches the same customer rather than a second one.

bermudalamb referenced this issue

2026-09-10 08:12:57 -05:00

Google 4: linking a Google identity to an existing account #343

bermudalamb referenced this issue

2026-09-10 08:13:08 -05:00

Google 5: life without a password #344

bermudalamb referenced this issue

2026-09-10 08:19:23 -05:00

feat(auth): groundwork for signing in with Google (#340) #346

bermudalamb referenced this issue

2026-09-10 08:50:05 -05:00

feat(auth): the Google sign-in round trip (#341) #347