Sprint 4 Closes: Social Sign-In, Password Reset, and the Cost of Doing Auth Right

Sprint 4 of the beer app closed today. Auth II — social sign-in, password reset, marketing consent — was scoped two days ago as seven GitHub issues sized to ship independently, and all seven shipped, each as its own pull request, merged one at a time. That's the sprint that was planned. This post is about the two problems that weren't on the plan, because they don't show up until you actually build the thing: what "delete my account" means for an app whose entire purpose is a permanent record of drunk beers, and how you let a signed-in customer attach a second login method without doing something insecure to get there.

One migration, first, on purpose

The sprint's own dependency order put a data migration first: a custom ApplicationUser class replacing Identity's bare built-in user, carrying a MarketingConsent field. Nothing glamorous, but everything downstream — the consent checkbox, eventually the OAuth-sourced profile data — needed it to exist before it could be used. Building it first instead of bolting it onto whichever story happened to need it first meant the migration got its own tests, its own review, and its own merge, instead of hiding inside someone else's diff.

Three providers, one shared decision

Google, Facebook, and Apple sign-in are three separate OAuth integrations, each with its own package, its own claim shapes, its own quirks. But underneath the provider-specific wiring, they all answer the same question the same way: does this verified email already belong to an account? If it does, link the new login to it. If it doesn't, create one. That logic — link-or-create-by-verified-email — got written exactly once, in a shared service, and each provider's story was really just "prove this provider's claim of a verified email, then hand it to the thing that already works."

Apple surfaced a case worth writing down rather than quietly living with: Sign in with Apple lets a customer share a private relay address instead of their real email, and Apple genuinely does verify that relay address — mail sent to it really does reach the person. But if that same customer already has a password account under their real email, the relay address won't match it, and the shared logic will correctly create a second account rather than guess that they're the same person. That's not a bug to patch. It's the honest limit of matching purely on email, and it's why account linking has to exist as its own feature rather than an assumption.

What "delete my account" means for a punch card

Facebook requires a working data-deletion callback before it approves a login integration, and building it forced a real decision, not a checkbox: what actually happens when a customer's account gets deleted?

The answer that fits this app is not "delete the row." The whole point of the product is a durable record — which beers a customer had confirmed, when, whether they earned the mug — and that record is arguably as much the tavern's ledger as it is the customer's data. So the deletion callback anonymizes: it scrubs the account's email and username, strips the password, and unlinks every connected provider, but leaves the confirmation history attached to the same (now anonymous) account row. It's the same shape as removing your name from a paper punch card behind the bar — the tavern's record that a mug was earned doesn't disappear, only the name attached to it does.

The problem with putting a bearer token in a URL

The account-linking screen — letting an already-signed-in customer attach Facebook to the Google account they registered with — looked simple until I actually tried to wire it up. Signing in and linking a provider both start the same way: the browser gets redirected to a full-page OAuth screen. But linking needs the server to know which account to attach the new login to, and a full-page redirect can't carry an Authorization header the way a normal API call can. The obvious shortcut — stick the JWT in the redirect URL as a query parameter — works, technically. It also means that token now lives in server access logs, browser history, and any proxy sitting in front of the API, for as long as those retain data.

The fix was a level of indirection instead: the signed-in customer's browser first makes a normal authenticated call to mint a random, single-use ticket, good for five minutes, stored server-side in the same in-memory cache the app already uses for caching brewery lookups. Then it redirects to the OAuth flow with that meaningless ticket in the URL instead of the real credential. The ticket resolves back to the customer's identity only on the server, only once, and expires either way. Nothing sensitive ever touches a URL. It's more moving parts than a query-string token would have been, but it's the difference between "convenient" and "the kind of thing that reads badly in a security review."

The PM angle

Partway through this sprint I got asked directly: what's the actual best practice for sequencing this work — should the next issue build on the current unmerged branch, or wait? The honest answer was that I'd already been doing it one way for three straight sprints — one branch, one PR, merged before the next branch starts — without ever writing that rule down anywhere. So I wrote it down, in the same document that already tracks the Definition of Done. That's a small thing, but it's the difference between a convention and a habit: a habit lives in one person's head and dies the day they stop doing it by feel; a convention is checkable, arguable, and survives being asked about.

Where the project stands

Four sprints in, and the beer app now has real login options beyond "invent a password" — plus the account-linking, data-deletion, and consent-capture machinery that a real product needs around social sign-in, not just the sign-in button itself. Test suites stand at 171 backend and 117 frontend, all green. One honest caveat, stated the same way in every one of this sprint's pull requests rather than glossed over: the actual browser round trip against live Google, Facebook, and Apple developer accounts hasn't been exercised end-to-end yet, since that needs real developer-console credentials this environment doesn't have. The account-linking and account-creation logic underneath it does have real test coverage — the part that's actually this app's problem to get right, versus the part that's just wiring up someone else's OAuth screen.

Next up: grooming the Admin Experience epic — a dashboard, an anomaly panel, real user and role management — into its own sprint. That grooming session hasn't happened yet.