LISTENER-ID-01 — Google and Apple Listener identity boundary

[nicoechaniz]

Objective

Provide isolated Harmonic Beacon Listener identity and sessions for registered Free and canonical membership without granting event capabilities.

Current state — accepted

• Google Authorization Code flow is deployed and human-accepted on canonical Listener, including logout/re-login.
• Replacement Google OAuth client/secret was deployed under LISTENER-SEC — Rotate exposed Google OAuth client secret #328; previous credentials were revoked.
• State/PKCE, replay and negative authorization remain fail-closed.
• Provider subject plus opaque canonical account is authoritative; email never grants access or Founder.
• Listener sessions grant no event tickets, staff, LiveKit, Myth Bot or Proyección del Mito authority.
• Universal email magic link LISTENER-ID-02 — Passwordless email magic-link fallback #217 is deployed through the isolated mail sidecar and accepted in a real browser: delivery → one-use callback → email-only Free session → logout.
• Facebook, implicit cross-provider linking and password/test login remain absent from public Listener.
• Apple is hidden and explicitly deferred until Apple Developer Program access, Team ID, App ID, Services ID, Key ID, private .p8/client-secret JWT, callbacks and 2FA are available. Apple does not block launch.

Acceptance

• Google state/PKCE, callback, logout, expiry and negative authorization tests.
• Real canonical Google login/logout/re-login.
• Controlled Google client-secret rotation and callback regression.
• No persisted OAuth token, session IP or user-agent; no cross-product capabilities.
• Founder continuity belongs to current canonical paid authority, not email/provider.
• Missing external-provider configuration fails closed without breaking Google.
• Magic-link request/delivery boundary deployed without modifying event identity/runtime.
• Real-browser magic-link callback→email-only Listener→Free→logout.
• Apple requirements documented and provider hidden until configured.

No identity slice changes event auth, audio, payments or live.harmonicbeacon.com.

[nicoechaniz]

Current Free-first checkpoint (2026-08-06): Google/Apple adapters, isolated Better Auth models/cookie/session boundary, callback routing, token scrubbing and negative tests are implemented on draft PR #203. Exact staging callbacks are https://earlybirds-staging.harmonicbeacon.com/api/early-birds/auth/callback/google and /apple. Runtime inspection confirms all four provider client ID/secret values are unset, and the public buttons truthfully render disabled. Remaining evidence is external provider registration/credentials plus real Google and Apple sign-in on staging; synthetic Free team entry covers acceptance until then without granting payment access.

[nicoechaniz]

OAuth implementation checkpoint (2026-08-07):

• Google Auth Platform project harmonic-beacon-listener created with exact Listener/staging origins and callbacks.
• Google audience is External and In production; only openid/email/profile are requested by the pinned Better Auth provider.
• A first accidentally exposed, unused client was deleted immediately. Its replacement was transferred directly to protected mona configuration; no local credential file remains.
• Public edge/code slice now exposes only /api/early-birds/auth/ while synthetic email entry, invitations and internal membership routes remain hidden. Focal auth and preview-contract tests are green.
• Apple remains externally blocked: the current browser has no authenticated Apple Developer Program session, so Services ID, primary App ID, key/team ID and generated client-secret JWT cannot yet be provisioned.

Free for All stays enabled until registered weekly Free windows are ready, so the accepted demo remains available during identity rollout.

[nicoechaniz]

Identity checkpoint deployed on isolated Listener at 575b75a:

• Google authorization starts successfully in a real Chromium session and reaches the Google account chooser for harmonicbeacon.com with the exact listen callback, state and PKCE S256. No real account was selected and no personal Listener row was created.
• The public API now requires an exact trusted Origin for browser-initiated auth mutations. Missing/foreign Origin returns 403; provider callbacks remain protected by one-time state/cookie verification and PKCE, including Apple form_post.
• Incomplete providers are absent from UI and runtime. Apple POST remains 404.
• OAuth access, refresh and ID tokens remain scrubbed. New session hooks also discard IP address and user-agent before Prisma writes.
• A synthetic staging login proved session creation, zero retained IP/user-agent fields and successful logout; anonymous session then returned null.
• Signed-in users outside their Free window now retain an explicit logout action.
• 1,087 tests, ESLint, TypeScript, production build and all GitHub checks passed. Public readiness and FFA lease are green.

Google completion still needs one supervised human selection/consent to exercise the real callback and inspect the resulting account. Apple remains blocked only by Apple Developer Program access, 2FA, Services ID/App ID, key/team ID and generated client-secret JWT.

[nicoechaniz]

Human Google acceptance passed on 2026-08-07: real callback returned to Listener; logout and sign-in again both worked. A sanitized server aggregate corroborated one recent provider identity/session while persisted OAuth tokens, session IP and user-agent remained absent. The human also selected a custom Free window one minute ahead and reached Listener after reload. No account identity or provider material is recorded here.\n\nApple remains fail-closed/hidden. Exact external inputs: Apple Developer Program Account Holder/Admin access with 2FA; a primary App ID enabled for Sign in with Apple; an associated Services ID (OAuth client ID); registered listen.harmonicbeacon.com and staging domains plus both absolute /api/early-birds/auth/callback/apple URLs; Team ID; Key ID; securely delivered one-time-download .p8; and a generated client-secret JWT. A normal Apple Account on an iPhone is sufficient only for physical acceptance after this configuration exists.