feat(auth): sign in with Google, and decide whether Apple follows #332

New Issue

2026-09-09T14:19:28-05:00

bermudalamb commented

2026-09-09 14:19:28 -05:00

Add social sign-in for customers. Google first; Apple is a separate decision with a materially different cost, set out below.

Do this before launch. Production is not live and there are no customer accounts, which makes the schema change free and the account-linking policy a design decision rather than a migration. Both get considerably more expensive the day real accounts exist — linking in particular, because a wrong policy applied to accounts that already exist is an account-takeover incident rather than a code change.

What already fits

More than expected, and most of it recent:

createSession and setSessionCookie are reusable as they stand. A social sign-in must end in exactly the same rd_session cookie, with the same flags, expiry and logout behaviour. A second, subtly different session path is how auth bugs get in.
attachCustomer needs no change. It reads a session; it does not care how one was created.
AuthForm.tsx is the single sign-in implementation, rendered by both AuthRouteModal and AuthPromptModal. The buttons go in one place, and the consent capture comes along for free.
The redirect URI derives from PUBLIC_URL, exactly as the WebAuthn RP ID does (#37). Same reasoning, same single source.
#38 has just established the pattern to copy: a table of credentials linked to customers, keyed on a provider-issued identifier.

The schema delta

customers.password_hash is NOT NULL, and a Google-only customer has no password. That is the change with the widest blast radius. Making the column nullable is trivial; auditing what assumes it is not is the actual work. The sites, all in routes/customers.ts:

Site	What it assumes
Registration `INSERT`	Always supplies a hash
Password reset	Sets `password_hash` and `email_verified = true`
Login	`bcrypt.compare` against a hash that exists
Change password	Compares the current one first
Account deletion	Confirms with the password

The last three become "this account has no password" cases rather than failures. Deletion and change-password need a different confirmation for a social-only account, and asking for a password that was never set is a dead end.

Plus a customer_identities table — provider, provider subject, customer id, created/last used — rather than columns on customers, because one customer may eventually hold both a Google and an Apple identity. Keyed on the provider's stable subject, never the email: emails change, and on Apple the email may not be real.

The decision that matters more than any of the code

Account linking. Someone registers with email and password, then later clicks Sign in with Google using the same address. Link automatically, or refuse?

Auto-link on a provider-verified email. Google asserts email_verified, so this is defensible for Google. It is an account-takeover path for any provider that does not, and it must never be done on an unverified one.
Refuse and require signing in the existing way first, then link deliberately from the account page. Safer, and worse to use.
Treat them as separate accounts. Simplest and wrong — two accounts, one person, one email, and orders split across both.

This is a security decision, not a preference, and it should be settled on this issue before implementation rather than discovered in the code.

Apple's Hide My Email makes it sharper. Apple can return a per-app relay address at @privaterelay.appleid.com, so the email is one that will never match anything else and linking on it is meaningless.

Google

Free, and the straightforward half.

OAuth client from Google Cloud Console; client id and secret per environment, alongside the existing secrets.
localhost redirect URIs are allowed, so local development works normally.
The sub claim is the stable identifier. email is not.
email_verified is asserted and is what makes auto-linking defensible.

Apple, and why it is a different category

The code is perhaps thirty percent more. The operational cost is not comparable:

$99/year Apple Developer Program. Not optional.
The client secret is a JWT signed with a .p8 key, and it expires — six months maximum. That is a recurring rotation task with an outage attached when it is missed. This project has exactly one such task today and it is already noted as unowned.
No localhost redirect URIs. Google allows them; Apple does not. The local development loop for this feature effectively disappears, and QA becomes the first place it can be exercised.
Name and email are returned only on the very first authorization. Miss that response and they are gone permanently — there is no second chance and no endpoint to ask again.

Worth deciding explicitly rather than by drift: Apple is a requirement for iOS App Store apps offering third-party sign-in, and this is a website. That rule does not apply here.

Interactions

#313 changes the domain, and redirect URIs are registered per-domain in both consoles. Unlike passkeys, this is recoverable configuration rather than destroyed credentials — but it is another list to update at the cutover, and it should be in that checklist.
#56's consent work applies unchanged. A social sign-up still has to capture marketing and analytics consent, with the same wording stored verbatim. AuthForm being the single implementation is what keeps that from drifting.
#33's disabled accounts must be refused here too, for the same reason #39 requires it of passkeys: enforcing it on one sign-in path and not another is how a disabled account keeps a way in.
This creates the project's first customers with no password, which quietly invalidates an assumption #40 rests on. Its note reads: "Removing the last passkey must not lock the customer out. Since password login remains available, this is safe today." Once social-only accounts exist, password login is not always available, and that check stops being theoretical.

Suggested shape

Google first, on its own, and Apple as a separate issue once Google is working. Most of the cost is shared — the identities table, the nullable hash, the linking policy, the router, the buttons — so Apple afterwards is genuinely incremental, and doing them together means paying Apple's operational cost before knowing whether the shared half is right.

Done when

A customer can sign in with Google, arriving at the same session a password login produces; a returning customer reaches the same account rather than a second one; the linking policy decided above is implemented and tested; a social-only account can be deleted and can manage itself without being asked for a password it never set; and a disabled account is refused.

Add social sign-in for customers. Google first; Apple is a separate decision with a materially different cost, set out below. **Do this before launch.** Production is not live and there are no customer accounts, which makes the schema change free and the account-linking policy a design decision rather than a migration. Both get considerably more expensive the day real accounts exist — linking in particular, because a wrong policy applied to accounts that already exist is an account-takeover incident rather than a code change. ## What already fits More than expected, and most of it recent: - **`createSession` and `setSessionCookie` are reusable as they stand.** A social sign-in must end in exactly the same `rd_session` cookie, with the same flags, expiry and logout behaviour. A second, subtly different session path is how auth bugs get in. - **`attachCustomer` needs no change.** It reads a session; it does not care how one was created. - **`AuthForm.tsx` is the single sign-in implementation**, rendered by both `AuthRouteModal` and `AuthPromptModal`. The buttons go in one place, and the consent capture comes along for free. - **The redirect URI derives from `PUBLIC_URL`**, exactly as the WebAuthn RP ID does (#37). Same reasoning, same single source. - **#38 has just established the pattern to copy**: a table of credentials linked to `customers`, keyed on a provider-issued identifier. ## The schema delta **`customers.password_hash` is `NOT NULL`, and a Google-only customer has no password.** That is the change with the widest blast radius. Making the column nullable is trivial; auditing what assumes it is not is the actual work. The sites, all in `routes/customers.ts`: | Site | What it assumes | | --- | --- | | Registration `INSERT` | Always supplies a hash | | Password reset | Sets `password_hash` and `email_verified = true` | | Login | `bcrypt.compare` against a hash that exists | | Change password | Compares the current one first | | Account deletion | Confirms with the password | The last three become "this account has no password" cases rather than failures. Deletion and change-password need a different confirmation for a social-only account, and asking for a password that was never set is a dead end. Plus a **`customer_identities`** table — provider, provider subject, customer id, created/last used — rather than columns on `customers`, because one customer may eventually hold both a Google and an Apple identity. Keyed on the provider's stable subject, **never the email**: emails change, and on Apple the email may not be real. ## The decision that matters more than any of the code **Account linking.** Someone registers with email and password, then later clicks Sign in with Google using the same address. Link automatically, or refuse? - **Auto-link on a provider-verified email.** Google asserts `email_verified`, so this is defensible for Google. It is an account-takeover path for any provider that does not, and it must never be done on an unverified one. - **Refuse and require signing in the existing way first**, then link deliberately from the account page. Safer, and worse to use. - **Treat them as separate accounts.** Simplest and wrong — two accounts, one person, one email, and orders split across both. This is a security decision, not a preference, and it should be settled on this issue before implementation rather than discovered in the code. **Apple's Hide My Email makes it sharper.** Apple can return a per-app relay address at `@privaterelay.appleid.com`, so the email is one that will never match anything else and linking on it is meaningless. ## Google Free, and the straightforward half. - OAuth client from Google Cloud Console; client id and secret per environment, alongside the existing secrets. - `localhost` redirect URIs are allowed, so local development works normally. - The `sub` claim is the stable identifier. `email` is not. - `email_verified` is asserted and is what makes auto-linking defensible. ## Apple, and why it is a different category The code is perhaps thirty percent more. The operational cost is not comparable: - **$99/year Apple Developer Program.** Not optional. - **The client secret is a JWT signed with a `.p8` key, and it expires — six months maximum.** That is a recurring rotation task with an outage attached when it is missed. This project has exactly one such task today and it is already noted as unowned. - **No `localhost` redirect URIs.** Google allows them; Apple does not. The local development loop for this feature effectively disappears, and QA becomes the first place it can be exercised. - **Name and email are returned only on the very first authorization.** Miss that response and they are gone permanently — there is no second chance and no endpoint to ask again. Worth deciding explicitly rather than by drift: Apple is a requirement for iOS App Store apps offering third-party sign-in, and this is a website. That rule does not apply here. ## Interactions - **#313 changes the domain**, and redirect URIs are registered per-domain in both consoles. Unlike passkeys, this is recoverable configuration rather than destroyed credentials — but it is another list to update at the cutover, and it should be in that checklist. - **#56's consent work applies unchanged.** A social sign-up still has to capture marketing and analytics consent, with the same wording stored verbatim. `AuthForm` being the single implementation is what keeps that from drifting. - **#33's disabled accounts must be refused here too**, for the same reason #39 requires it of passkeys: enforcing it on one sign-in path and not another is how a disabled account keeps a way in. - **This creates the project's first customers with no password**, which quietly invalidates an assumption #40 rests on. Its note reads: "Removing the last passkey must not lock the customer out. Since password login remains available, this is safe today." Once social-only accounts exist, password login is *not* always available, and that check stops being theoretical. ## Suggested shape Google first, on its own, and Apple as a separate issue once Google is working. Most of the cost is shared — the identities table, the nullable hash, the linking policy, the router, the buttons — so Apple afterwards is genuinely incremental, and doing them together means paying Apple's operational cost before knowing whether the shared half is right. ## Done when A customer can sign in with Google, arriving at the same session a password login produces; a returning customer reaches the same account rather than a second one; the linking policy decided above is implemented and tested; a social-only account can be deleted and can manage itself without being asked for a password it never set; and a disabled account is refused.

bermudalamb referenced this issue from a commit

Phase	Issue	Landed
Groundwork	#340	Nullable password hash, `customer_identities`, config derived from `PUBLIC_URL`
The round trip	#341	Code flow with PKCE, state and nonce, claim verification
New accounts	#342	Account creation, and the consent step
Linking	#343	The policy, implemented and pinned
No password	#344	Every route that assumed one exists
The button	#345	UI, public config flag, ops documentation

feat(auth): sign in with Google, and decide whether Apple follows #332

What already fits

The schema delta

The decision that matters more than any of the code

Google

Apple, and why it is a different category

Interactions

Suggested shape

Done when

Done, in six phases

The decisions this issue asked for

Two things this issue recorded that turned out to be wrong

Still not offered

Not yet verified by CI

Correction to the closing summary

What this changes

Where it was written down

Worth carrying forward