santi020k auth

Reusing authentication policy without sharing accounts

I built santi020k auth for a recurring problem across my Cloudflare applications: the security-sensitive protocol work was similar, but the identity state and product responsibilities needed to stay separate.

The first public adapter, @santi020k/auth-cloudflare, provides email-code and passkey authentication for single-owner and multi-user Hono applications running on Cloudflare Workers and D1. The source repository is open under the MIT license, and the package is available as an experimental 0.x release.

Goals

• Reuse reviewed authentication policy without creating a shared account system across products.
• Keep every browser boundary explicit through exact application origins, cookie prefixes, and WebAuthn relying-party IDs.
• Make secure behavior reviewable with D1 integration tests, package-contract checks, browser tests, and documented adoption gates.
• Support gradual migration while each product preserves its existing login and recovery path until the new flow is proven on its real origin.

What I built

• A typed Better Auth policy layer with single-owner and application-owned multi-user membership policies for Hono applications on Cloudflare Workers.
• Email-code authentication with hashed codes, ten-minute expiry, limited verification attempts, and success-shaped responses that do not reveal whether an address is authorized.
• Passkey support that requires discoverable credentials and user verification for the exact application hostname.
• Durable rate limiting in D1 instead of isolate memory that disappears when a Worker is recycled.
• Server, browser client, Hono middleware, and schema exports so consumers can integrate the package without reaching into private modules.
• A local playground and documentation website for reviewing the complete flow, security boundary, migration steps, and release status.

The isolation contract

The package owns protocol policy and reusable integration code. It does not own a product’s users.

Every consuming application keeps its own D1 database, additive migrations, authentication secret, cookie namespace, hostname, passkeys, email delivery, authorization rules, recovery process, and deployment. Sessions never cross application boundaries, and adopting the package never turns separate products into one identity platform.

Security and release discipline

• Exact-origin requests: credentialed browser requests are accepted only from the configured application origin.
• Current membership: only the configured owner or an email approved by the consumer’s live membership policy may create or update a user; multi-user sessions and authenticated passkey operations recheck access so removal does not wait for session expiry.
• Production transport: non-local origins require HTTPS and secure cookies.
• Private vulnerability reporting: security reports follow the repository’s documented private channel rather than public issues.
• Evidence before stability: repository checks can prove package behavior, but real email delivery, recovery, migrations, and passkeys must still be verified on each consumer’s production origin.

Why it matters

Authentication reuse becomes dangerous when sharing code quietly turns into sharing identity state. The stronger boundary is narrower: standardize the protocol decisions that should be reviewed once, then make every product remain responsible for its own data and operational recovery.

That is what santi020k auth provides. It is public so the policy and implementation can be inspected, tested, and improved in the open. It remains explicitly experimental while real consumers produce the evidence needed for a stable contract.

Read the documentation, install the package from npm, or explore the source on GitHub.