Authentication service on the harness

[ParallelEntrepreneur]

What this is. One authentication service, auth.factory0.ventures, that every venture backend delegates to. Six login methods resolve to one session: passkeys, Google, Apple, Meta, email and password, magic links. Consuming apps are registered clients with their own id, secret and exact redirect URIs. They receive tokens they can verify locally with a thin client crate.

How it fits the harness. The service is a consumer of the harness, not a change to it. It is a venture-shaped backend in the sense of ADR 0003: one Worker, one D1 database, its own secrets, its own domain. Its features are harness modules (auth-core, auth-passkeys, auth-oidc, auth-apple, auth-meta, auth-password, auth-magic-link) that see only ports. Every port it needs already exists: Database for users, sessions and single-use tokens; KeyValue for nothing that must be single-use (see below); HttpClient for provider token exchanges and the Graph API; Mailer for magic links; RateLimiter and Captcha for the password and magic-link endpoints; Signer for short-lived HMAC state; Clock and IdGen. Multi-app support is the clients table and an OAuth 2.1 authorization-code flow with PKCE, because consuming apps live on other domains (undercoverrockstars.com, kontinuum.audio) and a cookie on auth.factory0.ventures cannot reach them. The venture backends then verify tokens with factory0-auth-client.

What the harness must gain first. Two small things, filed in the harness repo as Cratefield/harness#46: modules can currently only mount under /v1/<name>, and this service must publish /.well-known/jwks.json and /.well-known/openid-configuration at the root; and axum's form extractor is not enabled in the core, which Apple's form_post callback requires.

Validated before writing this. webauthn-rs 0.5.5 has OpenSSL as a hard dependency through webauthn-rs-core and webauthn-attestation-ca, with no feature to turn it off, so it does not compile for wasm32-unknown-unknown. openidconnect 4, oauth2 5 and argon2 0.6 all build to wasm32 with default features off and no OpenSSL or reqwest in the tree. The passkey spike therefore starts from a known failure and evaluates the alternatives. Two more facts shape the schema: Cloudflare KV is eventually consistent, so anything that must be single-use (magic-link tokens, WebAuthn challenges, authorization codes) lives in D1 with delete-on-use, never in KV; and argon2 on Workers is CPU-bound in wasm, so its parameters are measured, not assumed.

Deferred. Enterprise SAML SSO is out of scope for this epic and has no issues. When a venture needs it, it becomes a separate epic on top of the same session and client model.

Order. Spikes first; then schema, client registration, sessions, tokens and the authorization flow; then the client crate and rate limiting; then each login method; account linking last because it depends on every provider's identity shape.

Children, in dependency order

• Spike: compile webauthn-rs and openidconnect to wasm32 for Workers #2 Spike: compile webauthn-rs and openidconnect to wasm32 for Workers
• Spike: Apple client secret minting, form_post callback and first-authorization name #3 Spike: Apple client secret minting, form_post callback and first-authorization name
• Spike: Meta as OAuth2 plus Graph profile, and the data deletion callback #4 Spike: Meta as OAuth2 plus Graph profile, and the data deletion callback
• D1 schema: users, identities, credentials, sessions, single-use tokens, clients #5 D1 schema: users, identities, credentials, sessions, single-use tokens, clients
• Client registration: id, hashed secret, allowed redirect URIs #6 Client registration: id, hashed secret, allowed redirect URIs
• Redirect URI validation: exact match only #7 Redirect URI validation: exact match only
• Sessions: issuing, validation, sliding expiry, revocation and logout #8 Sessions: issuing, validation, sliding expiry, revocation and logout
• Decide and implement token issuing: signed JWT with JWKS versus opaque tokens with introspection #9 Decide and implement token issuing: signed JWT with JWKS versus opaque tokens with introspection
• Authorization code flow with PKCE for consuming apps #10 Authorization code flow with PKCE for consuming apps
• Client crate: verify tokens in consuming apps without reimplementing validation #11 Client crate: verify tokens in consuming apps without reimplementing validation
• Rate limiting and lockout on password and magic-link endpoints #12 Rate limiting and lockout on password and magic-link endpoints
• Passkeys: registration #13 Passkeys: registration
• Passkeys: login #14 Passkeys: login
• Google: registration and login via openidconnect #15 Google: registration and login via openidconnect
• Apple: registration and login with minted client secret and form_post #16 Apple: registration and login with minted client secret and form_post
• Meta: login via OAuth2 and Graph profile #17 Meta: login via OAuth2 and Graph profile
• Meta: data deletion callback endpoint #18 Meta: data deletion callback endpoint
• Email and password: registration with argon2 #19 Email and password: registration with argon2
• Email and password: login #20 Email and password: login
• Magic links: request and consume #21 Magic links: request and consume
• Account linking: one user, many identities, and the email-match rules #22 Account linking: one user, many identities, and the email-match rules

[ParallelEntrepreneur]

A2 progress: passkeys are in (#30, c6b2eed)

crates/auth-passkeys closes #13 and #14: registration and login, ES256 plus RS256 plus EdDSA, discoverable credentials, and passkey management on the account. 51 tests in the crate, 181 across the workspace, six CI jobs green.

The pattern the other login methods should follow. auth-core owns the schema and already published the typed store API, so this module declares no tables and ships no migrations; the one column it needed went into auth-core as 0004. #15 through #21 can all be shaped the same way.

Two things the review turned up that are worth carrying into those issues:

• A login method must check users.status. Only the token endpoint enforced the kill switch, so a passkey login handed a disabled account a session. Every other method will have the same hole unless it is written in from the start.
• An endpoint that acts permanently on a failure has to verify first. The passkey counter check ran before the signature check, which made a one-request, unauthenticated, permanent lockout of any stranger's credential. Anything in Email and password: registration with argon2 #19 to Magic links: request and consume #21 that locks out or flags on failure needs the same scrutiny about what has actually been proven at that point.

Filed from the review: #31, step-up authentication before adding or removing a credential. It belongs in auth-core rather than in one module, because every login method will want the same rule.

Left in A2: #15 (Google, no spike needed — openidconnect was validated in #2), #16 and #17 and #18 (blocked on the #3 and #4 spikes), #19 to #21 (password and magic links, which also want #12). Google is the obvious next one.

[ParallelEntrepreneur]

A2 progress: Google is in (#32, 4c26771)

crates/auth-oidc closes #15. Google is the first provider and the flow is written against a descriptor, so #16 should be an entry in provider.rs, two config keys, and whatever Apple insists on doing differently. 43 tests in the crate, 226 across the workspace.

Two things every remaining login method needs, both found by review rather than by me:

• Account status is not a per-method decision. A disabled account could sign in through Google, because only the token endpoint enforced users.status and the passkeys module happened to check it by hand. It now lives in sessions::issue, which is the one funnel every method goes through, so Apple: registration and login with minted client secret and form_post #16 to Magic links: request and consume #21 inherit it whether or not their authors think about it. I had written the warning about this on this very issue four hours earlier and then walked into it, which is the argument for putting rules in code rather than in comments.
• A first login that loses a race must clean up after itself. Insert-user-then-link is not atomic, and the loser's orphan row carries an email with no identity — which a later verified-email match from another provider would happily link a stranger to.

A harness bug this flow surfaced. FetchClient attached a body to every request including GETs, which the Fetch spec refuses, so OIDC discovery and the JWKS fetch would each have thrown inside the isolate and every sign-in would have answered 502 with the wasm build staying green. Nothing caught it because every adapter shipped so far POSTs. Fixed in Cratefield/harness#83; the pin moved forward in #34.

Also filed: #33, the login chooser still offers nothing. Passkeys and Google both work and neither is reachable from /authorize, and wiring it needs a decision about methods that need a page rather than a link.

Left in A2: #16, #17, #18 (blocked on the #3 and #4 spikes), #19 to #21 (password and magic links, which also want #12). The Apple spike is the next thing that unblocks anything.